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PREFACE 



This Software Release Bulletin documents all fixes and enhancements that 
are incorporated in the new release identified on the cover page. The 
SRB is provided as a benefit of Hewlett-Packard's Account Management 
Support, Response Center Support, and Software Materials Subscription. 

Of the five sections contained in the SRB (not including the PREFACE), 
only the last section which contains the detailed reports has page num- 
bers. These are referenced by the product, report number and keyword 
indexes in order to direct the user to a particular area or to an in- 
dividual detailed report. The five sections are described below. 

SOFTWARE RELEASE CONTENTS 

This section lists the product names, numbers and update/fix levels of 
all products contained in this release. Products that have changed, or 
are new are denoted with an asterisk preceding the product name. 

PRODUCT INDEX 

Each unique product name/number has an entry listing the page number 
where the detailed report for that product begins. 

REPORT NUMBER INDEX 

This index is a sequential list of the individual report numbers with 
the corresponding page number where the report can be found. 

KEYWORD INDEX 

This index is sorted by product name, keyword, product number (including 
the update/fix level) and by report number in that order. In addition 
to the sort items, each entry has a brief description (one line) and the 
page number where the detailed report can be found. Note that a given 
report can be listed more than once in this section if it has more than 
one keyword assigned to it. 

DETAILED REPORTS 

Each report contains all the available information relevant to the 
problem being corrected or the enhancement being implemented. 



Software release contents 



Product name 

*61+000-UX OP-ENV 
*6800 C 
*6800 C 
*6800 C 
*6800 C 
*6800 PASCAL 
*6800 PASCAL 
*6800 PASCAL 
*6800 PASCAL 
*680OO ASSEMB 
*680O0 ASSEMB 
*68000 ASSEMB 
*68000 ASSEMB 
*68000 C 
*68000 C 
*68000 C 
*68000 C 
*680O0 PASCAL 
*68000 PASCAL 
*680OO PASCAL 
*68000 PASCAL 
*68000C AXLS COMP 
*6809 C 
*6809 C 
*6809 C 
*6809 C 
*6809 PASCAL 
*6809 PASCAL 
*6809 PASCAL 
*6809 PASCAL 
*78310/12 ASSEMB 
*80286B ASSEMB 
*80286B ASSEMB 
*80286B ASSEMB 
*80286B ASSEMB 
*8085 B PASCAL 
*8085 B PASCAL 
*8085 B PASCAL 
*8085 B PASCAL 
*8085 C 
*8085 C 
*8085 C 
*8o85 C 

*8085 EMULATION 
*8086/8 ASSEMB 
*8086/8 ASSEMB 
*8086/8 ASSEMB 
*8o86/8 ASSEMB 
*8086/8 C 
*8o86/8 C 
*8086/8 C 
*8o86/8 C 
*8086/8 PASCAL 
*8086/8 PASCAL 
*8086/8 PASCAL 



Product number uu.ff 



300 61+801S001* 

6H821 
300 61+821S001+ 
500 61+821S001 
VAX 61+821S003 

61+811 
300 61+811S0014 
500 6U811S001 
VAX 6U811S003 

61+81+5 
300 61+81+5S001+ 
500 6I+8U5SOOI 
VAX 61+81+5S003 

61+819 
300 61+819S001+ 
500 61+819S001 
VAX 61+819S003 

61+815 
300 61+815SO01+ 
500 61+815S001 
VAX 61+815S003 
300 61+9O2S00U 

61+822 
300 61+822SO01+ 
500 61+822S001 
VAX 61+822S003 

61+813 
300 61+813S001+ 
500 61+813S001 
VAX 61+813S003 

61+866 

6I+859 
300 61+859SOOU 
500 6I+859SOOI 
VAX 6I+859SOO3 

61+825 
300 6U825S001+ 
500 61+825S001 
VAX 61+825S003 

61+826 
300 6U826S001+ 
500 61+826S001 
VAX 61+826S003 

61+203 

61+853 
300 61+853S001+ 
500 61+853S001 
VAX 61+853S003 

61+818 
300 61+818S001+ 
500 61+818S001 
VAX 61+818S003 

61*811+ 
300 61+811+S001+ 
500 61+811+S001 



01.80 

02.10 

02.10 

02.10 

02.10 

01.90 

01.90 

01.90 

01.90 

02.10 

02.10 

02.10 

02.10 

02.10 

02.10 

02.10 

02.10 

01.90 

01.90 

01.90 

01.90 

01.00 

01.80 

01.80 

01.80 

01.80 

01.60 

01.60 

01.60 

01.60 

01.02 

01.30 

01.30 

01.30 

01.30 

01.90 

01.90 

01.90 

01.90 

02.10 

02.10 

02.10 

02.10 

01.07 

02.70 

02.70 

02.70 

02.70 

03.70 

03.70 

03.70 

03.70 

03.50 

03.50 

03.50 



Software release contents 



Product name 




Product number 


uu.ff 


*8086/8 PASCAL 


VAX 


6U81US003 


03.50 


* 99 00/0 ASSEMB 




6H8147 


01.80 


*9900/O ASSEMB 


300 


6U8U7SOOU 


01.80 


*99O0/O ASSEMB 


500 


6U8I47SOOI 


01.80 


*9900/0 ASSEMB 


VAX 


61481+7S0O3 


01.80 


*F9U50 EMULATION 




6U286 


01.05 


*H0ST SOFTWARE / 


VAX 


6W82 


02.30 


*HOST SOFTWARE / 


300 


6U883 


01.10 


*HOST SOFTWARE / 


500 


•6U880 


01.80 


*MS1750A ASSEMB 




6^857 


01.90 


*MS1750A ASSEMB 


300 6U857S00U 


01.90 


*MS1750A ASSEMB 


500 6U857S0O1 


01.90 


*MS1750A ASSEMB 


VAX 


6U857S003 


01.90 


*OPERATING SYSTEM 




6I4IOO 


02.10 


*RS-232 TRANSFER 


300 


6U885 


01.30 


*RS-232 TRANSFER 


500 


6U88U 


01.30 


*RS-232 TRANSFER 


VAX 


61+886 


01.50 


*TMS 32010 MODULES 


6U285 


01.02 


*USER DEF ASSEMB 


300 


6U85ISOOU 


02.10 


*USER DEF ASSEMB 


300 


6lt86lSOOU 


02.10 


*USER DEF ASSEMB 


500 


6U85ISOOI 


02.10 


*USER DEF ASSEMB 


500 


6U861S001 


02.10 


*USER DEF ASSEMB 


VAX 


6I4851SOO3 


02.10 


*USER DEF ASSEMB 


VAX 


6U861S003 


02.10 


*USER DEF EMULATION 


61+27*4 


01.06 


*USER INTERFACE 


300 


6U808SOOU 


02.10 


*USER INTERFACE 


500 


61+808S001 


02.10 


*Z80/NSC800 C 




6U82U 


02.10 


*Z80/NSC800 C 


300 


6i+82l+S00l+ 


02.10 


*Z80/NSC800 C 


500 


6U82USOOI 


02.10 


*Z80/NSC800 C 


VAX 


6U82I+SOO3 


02.10 


*Z80/NSC800PASCAL 




61+823 


01.90 


*Z80/NSC800PASCAL 300 6U823S00U 


01.90 


*Z80/NSC800PASCAL 


500 


6U823S001 


01.90 


*Z80/NSC800PASCAL 


VAX 


6U823S003 


01.90 


*Z8000 C 




61+820 


02.10 


*Z8000 C 


300 


6U820S001+ 


02.10 


*Z8000 C 


500 


61+820S001 


02.10 


*Z8000 C 


VAX 


61+820S003 


02.10 


*Z8000 PASCAL 




61+816 


01.90 


*Z8000 PASCAL 


300 


6t*8l6S00t+ 


01.90 


*Z8000 PASCAL 


500 


6U816SOOI 


01.90 


*Z8000 PASCAL 


VAX 


61+816S003 


01.90 


*Z8002 EMULATION 




61+233 


02.01 



Product index 



Product name 



Product number 



Page 



6I4OOO-UX OP-ENV 300 
6800 C 
6800 PASCAL 
68000 ASSEMB 
68000 C 
68000 PASCAL 

6809 C 

6809 PASCAL 
80286B ASSEMB 
8085 B PASCAL 

8085 C 

8085 EMULATION 
8086/8 ASSEMB 
8086/8 ASSEMB 300 
8086/8 ASSEMB VAX 
8086/8 C 

8086/8 C 300 
8086/8 c 500 
8086/8 PASCAL 
9900/0 ASSEMB 
F91+50 EMULATION 
HOST SOFTWARE / VAX 
HOST SOFTWARE / 300 
HOST SOFTWARE / 500 
OPERATING SYSTEM 
TMS 32010 MODULES 
USER DEF ASSEMB 500 
USER DEF ASSEMB VAX 
USER DEF EMULATION 
USER INTERFACE 300 
Z80/NSC800 C 
Z80/NSC800 C 300 
Z80/NSC800PASCAL 
Z80/NSC800PASCAL VAX 
Z8000 C 
Z8000 PASCAL 
Z8002 EMULATION 



6WOISOOI4 

6U821 

6U811 

6U8U5 

6U819 

6U815 

6U822 

6U813 

6U859 

6U825 

6U826 

6U203 

6U853 

6U853S00U 

6U853S003 

6U818 

6J4818SOOU 

6U818S0O1 

6U8U+ 

6U8U7 

6U286 

6U882 

6U883 

6U88O 

6U100 

6U285 

6U85ISOOI 

6U851S003 

6U27 1 * 

6W08S0OU 

6U82U 

6U82USOOU 

6U823 

6i*823S003 

6U820 

6U816 

6U233 



1 

8 

1U 

19 

20 

26 

31 

3h 

38 

39 

k3 

U9 

50 

5U 

55 

56 

82 

83 

8U 

105 

106 

108 

109 

110 

112 

116 

117 

118 

119 

121 

12U 

132 

133 
1^5 
1U6 
ll»9 
153 



Report number index 



Report # 


page 


Report # 


page 


Report # 


page 


Report # 


page 


165000U598 


50 


500017065U 


124 


D200014340 


23 


D200071423 


140 


16500014705 


84 


50001 7112U 


20 


D200015073 


9 


D200071431 


128 


I65OOO6908 


112 


5000171876 


89 


D2000153^7 


9 


D200072371 


76 


16500081409 


8 


5000171884 


89 


D200019265 


111 


D20O073O31 


141 


I65OOO9I456 


26 


5000171900 


90 


D200019273 


92 


D200074237 


77 


1650011585 


133 


5000172239 


64 


D200022137 


92 


D200075044 


128 


1650013235 


50 


5000172593 


51 


D200023283 


92 


D200075861 


15 


1650018689 


84 


50001727^2 


43 


D200025858 


71 


D2000759H 


34 


1650018721 


110 


5000172825 


124 


D200027953 


114 


D200075952 


100 


165001922U 


26 


5000173278 


125 


D200031476 


72 


D200076026 


149 


1650019257 


108 


5000181552 


113 


D200035220 


105 


D200076067 


142 


1650019331 


27 


500018201U 


135 


D200038778 


127 


D200076109 


40 


1650026583 


20 


5000185066 


1 


D200042606 


72 


D200076588 


2 


1650026708 


56 


5000186718 


65 


D200043828 


120 


D200076620 


2 


1650033209 


112 


50001867U2 


135 


D200046623 


120 


D200076679 


3 


1650036525 


121 


5000188839 


21 


D200049916 


73 


D20007676O 


146 


1650038281 


1 


5000189985 


113 


D200053710 


93 


D200076802 


11 


1650038U30 


82 


5000190629 


136 


D200057802 


74 


D200076844 


31 


1650038521 


121 


5000193^66 


65 


D200060509 


52 


D200076919 


45 


2700005520 


56 


5000195628 


67 


D200061556 


19 


D200077008 


3 


500O1O3U32 


85 


500019762U 


90 


D200062604 


114 


D200077065 


24 


5000111666 


112 


5000201012 


51 


D200063123 


14 


D200077107 


146 


5000116848 


Ik 


50002017U9 


68 


D200063719 


34 


D200077149 


11 


5000118844 


85 


5000202770 


113 


D200063750 


94 


D200077180 


31 


5000121830 


105 


5000202846 


43 


D200063792 


28 


D200077222 


129 


500012U313 


86 


5000203596 


69 


D200063834 


149 


D200077263 


46 


500013^593 


57 


500020U586 


22 


D200063875 


137 


D200077396 


79 


500013^601 


57 


5000206649 


22 


D200063909 


39 


D200077495 


121 


500013U817 


87 


5000207845 


90 


D200064212 


39 


D200077727 


79 


5000136085 


50 


5000216036 


70 


D200065060 


94 


D200077768 


52 


5000136267 


58 


5000217927 


136 


D200066357 


107 


D200077875 


101 


5000137869 


153 


5000219204 


110 


D200066761 


137 


D200077941 


3 


5000138388 


87 


5000220186 


43 


D200067629 


10 


D200077958 


4 


50001U9229 


59 


5000221788 


83 


D200068403 


44 


D200078642 


101 


50001U9757 


60 


5000221994 


91 


D200068684 


74 


D200078923 


7 


5OOOII49765 


61 


5000223099 


23 


D200068759 


96 


D200079038 


5 


5000151^31 


153 


5000223792 


116 


D200068767 


98 


D200079079 


129 


5000152918 


1*9 


5000223800 


70 


D200068825 


38 


D200079087 


46 


5000161000 


133 


5000224022 


106 


D200068957 


107 


D200079095 


5 


500016103U 


134 


5000224204 


145 


D200069104 


108 


D2000791H 


80 


5000162U87 


62 


5000226605 


132 


D2OOO69666 


24 


D200079129 


25 


5000163287 


13>4 


5000226613 


54 


D200070532 


74 


D200079137 


146 


5000163^10 


63 


5000229476 


71 


D200070615 


75 


D200079145 


11 


500016382U 


88 


5000231605 


125 


D200071332 


138 


D200079152 


31 


5000164004 


106 


5000232959 


105 


D200O7134O 


139 


D200079160 


47 


5000165134 


63 


5000233866 


126 


D200071365 


139 


D200079178 


16 


50001691*74 


1 


5000234237 


23 


D200071373 


127 


D200079186 


35 


5000170415 


51 


5000241562 


119 


D200071415 


154 


D20OO79194 


103 



Report number index 

Report # page Report # page 



D200079202 28 

D200079210 150 

D200079228 Ul 

D200O79236 17 

D2000792UU 36 

D2O0O79251 10U 

D200079269 29 

D200079277 151 



D200079285 U2 

D200079293 5 

D200079301 1U3 

D200079335 55 

D200079509 6 

D200080051 81 

D200080093 6 

D200080101 7 



Report # page Report # page 



D200080135 122 

D2OO08O333 81 

D2OO08O3U1 1U7 

D20O08O358 12 

D20O08O366 32 

D20O08O37U 130 

D200080382 kj 

D200080721 122 



D2000811U1 122 

D20008ll*71 130 

D200081620 117 

D200081638 118 

D20008198U 6 

D200082636 109 

D200082669 108 

D200085050 115 



Keyword index 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64801S004 


01.00 


64801S004 


01.00 


64801S004 


01.00 


64801S004 


01.00 


64801S004 


01.50 


64801S004 


01.50 


64801S004 


01.50 


64801S004 


01.50 


64801S004 


01.60 


64801S004 


01.60 


64801S004 


01.60 


64801S004 


01.60 


64801S004 


01.60 


64801S004 


01.60 


64801S004 


01.60 


64801S004 


01.70 


ENHANCEMENT 64801S004 


01.60 



No error message given when opt run on memory board. 

Edbuild does not work whether invoked by the user or the emulator. 

Msinit may autoconf igure incorrectly. 

HP enhancements are too slow to run softkeys. 

If second card cage used in pv , it may not be released 

Pressing return during a cycle command causes pv to hang 

Msinit crashes opt test user. 

If /usr/hp64000/lock does not exist, msconfig gives odd messages. 

pwd truncates the /net/system portion of the path when RFA'ed to system. 

Search command files via "PATH" variable 

option test multitest can't handle more than 24 cards 

EDBUILD IS NOT WORKING PROPERLY 

Incompatible /etc/update programs. 

64000-UX processes do not die when modem carrier is lost. 

Processes sometimes left running after parent has stopped'. 

Multiple <cr> after selecting card will leave softkeyw in an odd state. 

64000-UX uses TERMINF0 database only partially. 



5000169474 


1 


5000185066 


1 


D200077941 


3 


D200077958 


4 


D200076588 


2 


D200076620 


2 


D200076679 


3 


D200077008 


3 


1650038281 


1 


D200078923 


7 


D200079038 


5 


D200079095 


5 


D200079509 


6 


D200080093 


6 


D200081984 


6 


D200079293 


5 


D200080101 


7 



- -8 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64821 

64821 
64821 

CODE GENERATOR 64821 

64821 
64821 
64821 

PASS 1 64821 



01.06 Assigning to bitfield causes entire structure to be reset. 

01.07 Array is being placed in the PROG section rather than data. 
01.07 Warning message text is incorrect. 
00.01 Nested IF stmnt. with bit field structure members genrate incorr. 



code 



D200067629 
D200076802 
D200080358 
1650008409 
D200015073 



01.04 Using a pointer dereference as an array index generates incorrect code 

01.04 Compiler doesn't reload register after value changes in a nested if expr D200015347 

oatinq point di ' " ' " « • * ». r..™«,.,-n , *« 

01.07 DIV, 



01.07 Floating point division of 2 constants generates incorrect result 
MOD and COMParisons may do unsigned estend of signed values 



D200077149 
D200079145 



10 

11 

12 

8 

9 

9 

11 

11 



- -8 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64811 

64811 

64811 

PASS 1 64811 

WITH 64811 



Keyword Product number 

********none******** 64845 



01.10 functional type change of a constant into multi-byte structure gen's err D200063123 



01.20 Unsigned_8 treated as signed value in FOR loop test 

01.20 Pascal does not report error for assignment of constant to structure 

01.20 Functional type changes not always evaluated correctly 

01.08 Generates bad code for parameter as ADDR of component. 

- -8 
uu.ff Description 

01.10 EQU is not working with DC correctly. 

- -8 



D200075861 
D200079178 
D200079236 
5000116848 



14 
15 
16 
17 
14 



Keyword 



Product number uu.ff Description 



Report # page 
D200061556 19 

Report # page 



********none******** 64819 

64819 
64819 



01.02 68008 libraries cause target processor disagree errors. 
01.09 Result is invalid if terenary expression evaluates to 
01.09 Two external declarations are made for one function. 



false . 



5000234237 


23 


5000171124 


20 


5000206649 


22 



Keyword index 



-8 



Keyword 



Product number uu.ff Description 



********none******** 64819 

64819 
64819 
64819 

CODE GENERATOR 64819 

64819 

ENHANCEMENT 64819 

PASS 1 64819 



01.09 Compiler aborts when it encounters a legal structure declaration. 

01.10 Invalid error 60 flagged. 

01.10 SLIST ON/OFFS doesn't work correctly. 

01.10 Wrong floating point value assigned in a terenary expression. 

01.07 Bad code using SRANGES or $DEBUG$ with $CALL_PC_LONG$ or $LIB_PC LONGS 

01.10 Floating point division of 2 constants generates incorrect resulT 

01.90 Generate XREF from compiler which is readable by EDT . 

01.10 DIV, MOD and COMParisons may do unsigned estend of signed values 



•8 



Keyword 



Product number uu.ff Description 



********none******** 64815 

64815 
64815 
64815 
64815 

PASS 1 64815 



00.01 System reboot for syntax error. 

01.10 Incorrect code generated for array which has boolean indites. 

01.10 Set manipulation results in incorrect code being generated. 

01.11 functional type change of a constant into multi-byte structure gen's err 

01.12 Pascal does not report error for assignment of constant to structure 
01.12 Functional type changes not always evaluated correctly 



- -8 



Keyword 



Product number uu.ff Description 



******** none ******** 64822 

64822 
CODE GENERATOR 64822 
PASS 1 64822 



01.08 Array is being placed in the PROG section rather than data. 

01.08 Warning message text is incorrect. 

01.08 Floating point division of 2 constants generates incorrect result 

01.08 DIV, MOD and COMParisons may do unsigned estend of signed values 



- -8 



Keyword 



Product number uu.ff Description 



Report # 


page 


D200069666 


24 


1650026583 


20 


5000188839 


21 


5000204586 


22 


D200014340 


23 


D200077065 


24 


5000223099 


23 


D200079129 


25 



Report # page 



1650009456 
1650019224 
1650019331 
D200063792 
D200079202 
D200079269 



26 
26 
27 
28 
28 
29 



Report # page 



D200076844 
D200080366 
D200077180 
D200079152 



31 
32 
31 
31 



Report # page 



********none******** 64813 

64813 
64813 

PASS 1 64813 



Keyword Product number 

********none******** 64859 



01.10 functional type change of a constant into multi-byte structure gen's err D200063719 

01.11 Unsigned_8 treated as signed value in FOR loop test. D200075911 
01.11 Pascal does not report error for assignment of constant to structure D200079186 
01.11 Functional type changes not always evaluated correctly D200079244 

- -0 



34 
34 
35 
36 



uu.ff Description Report # page 

01.02 Assembling on 64100 & linking on VAX generates erroneous absolute file D200068825 38 

- -0 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64825 

64825 

64825 

PASS 1 64825 

PASS 2 64825 



01.03 functional type change of a constant into multi-byte structure gen's err D200063909 39 

01.04 Unsigned_8 treated as signed value in FOR loop test. D200076109 40 
01.04 Pascal does not report error for assignment of constant to structure D200079228 41 
01.04 Functional type changes not always evaluated correctly D200079285 42 
01.03 Incorrect code generated when set elements are passed as parameters. D200064212 39 



Keyword index 



- -0 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64826 

64826 
R 4,826 

CODE GENERATOR 64826 

64826 
64826 
64826 
64826 

PASS 1 64826 



Keyword Product number 

***X****none******** 64203 



01.03 Expression used as array index generates incorrect code. 

01.04 Array is being placed in the PROG section rather than data. 
01.04 Warning message text is incorrect. 

01.03 bad code generated with *pointer++ operation 

01.04 > = does not work with float type 

01.04 When subtract an integer from a pointer, get unnecessary warning message 
01.04 Floating point division of 2 constants generates incorrect result 
01.04 +=, -=, *=, & /= may fail to auto vars with SRECURSIVE 0N$ 
01.04 DIV, MOD and COMParisons may do unsigned estend of signed values 



uu.ff Description 

01.06 Can't use 9.5" paper to print mem map, due to centering of printout. 

- -0 



D200068403 


44 


D200076919 


45 


D200080382 


47 


5000172742 


43 


5000202846 


43 


5000220186 


43 


D200077263 


46 


D200079087 


46 


D200079160 


47 


Report # 


page 


5000152918 


49 



Keyword 



Product number uu.ff Description 



Report # page 



****#***none******** 64853 

64853 
64853 
64853 
64853 
CODE GENERATOR 64853 
LINKER 64853 

64853 



02.00 Assembler/linker does not correctly handle EQU <EXT_LABEL> statement 

02.01 Wrong values during EQU from externals. 

02.01 reusing accumulator 

02.03 Tabs in source file are expanded to 6 spaces instead of 8 spaces 
02.03 The noload files aren't showing up in the listing; absolute correct 

02.02 Incorrect Object code generated 
02.01 Linker generates error if COMN segment is not 0000H 



5000136085 
1650004598 
D200077768 
1650013235 
5000170415 
5000201012 
D200060509 



02.03 Label preceeded with WORD PTR.NEAR PTR , etc. will not appear in the xref 5000172593 



50 
50 
52 
50 
51 
51 
52 
51 



Keyword 
LINKER 

Keyword 

CODE GENERATOR 

Keyword 



Product number 
64853S0C4 

Product number 
64853S003 



- -0 
uu.ff Description 

02.20 Linker can generate invalid DATE on listing file. 

- -0 
uu.ff Description 

02.50 VMS Hosted linker does not recognize logical names 

- -0 



Product number uu.ff Description 



Report # page 
5000226613 54 

Report # page 
D200079335 55 

Report # page 



********none******** 64818 

64818 
64818 
64818 
64818 
64818 
64818 
64818 
64818 



02.00 Using a postfix decrement operator in a conditional statement fails. 
02.00 Compiler uses wrong segment register. 

03.00 DX register is used although it is overwritten by IMUL instruction 

03.01 ES reg overwritten when assign char array to complex data structure 

03.02 Code generated for illegal C statement - POP BH generated 
03.02 Address of array element incorrectly calculated 

03.02 external used 2x in same pgm, w/ ASM FILE ON, get 2 EXT stmts in ASMfile 
03.02 PROGRAMS WITH DUPLICATE GOTO LABELS RAY FAIL IN PASS 3 
03.02 Warning message text is incorrect. 



D200031476 


72 


D200042606 


72 


D200049916 


73 


5000195628 


67 


5000149757 


60 


5000149765 


61 


5000172239 


64 


D200074237 


77 


D200080333 


81 



Keyword index 



Keyword 

CODE GENERATOR 



Product number uu.ff Description 



Report # page 



LINKER 
PASS 1 

RUN-TIME LIBRARY 
SFlOOi 



Keyword 

CODE GENERATOR 

Keyword 

CODE GENERATOR 



Keyword 



64818 


01.06 


64818 


02.01 


64818 


02.01 


64818 


02.01 


64818 


03.00 


64818 


03.00 


64818 


03.01 


64818 


03.01 


64818 


03.01 


64818 


03.01 


64818 


03.01 


64818 


03.01 


64818 


03.02 


64818 


03.02 


64818 


03.02 


64818 


03.02 


64818 


03.02 


64818 


03.02 


64818 


03.02 


64818 


03.20 


64818 


03.30 


64818 


03.10 


64818 


03.02 


64818 


03.02 


64818 


00.00 


64818 


03.02 


Product number 


uu.ff 


64818S004 


03.02 



Product number 
64818S001 



Argument to switch statement may be doubled. 

1102 error generated - register needed but not availiable 

Incorrect segment of array transfered to pointer 

ES register corrupt when used to get address of array to place in ptr. 

Return statement not putting value on BX register 

Nonsense code generated by dynamic struc declaration in a funct. 

Right shift using var. for # of places to shift generates bad code 

Floating point division of 2 constants generates incorrect result 

When using calculated value for array index, uses BX register twice 

Compile incorrect when a ptr to an int is casted as a short and incremen 

Incorrect segment passed to external function 

Assignment to ptr var. (w/ Separate const off) causes corrupt stack 

Vax not creating same code as the 64~000 

BX register overwritten with a switch statement 

Bad code generated for address of external character if for loop 

Incorrect segment passed to external function 

VAX and 64100 generate different constants. VAX is incorrect. 

CL register being used twice 

Cannot prevent adding Esymbol and Rsymbol info to global symbol table 

compiler reusing CX register 

Problem w/ unreleased Rev. Dx Register destroyed 

The noload files aren't showing up in the listing, absolute correct 

compiler using DS segment rather than ES segment for 32 bit pointers 

DIV, MOD and COMParisons may do unsigned esfend of signed values 

REAL NUMBER COMPARISONS MAY NOT EVALUATE CORRECTLY. 

When casting unsigned ints to floats using += , generates a error #1001 



03.02 printer arithmetic gives warning "integer not pointer size" 

- -0 



D200025858 
5000134593 
5000134601 
5000136267 
5000149229 
D200057802 
1650026708 
5000186718 
5000193466 
D200068684 
D200070615 
D200072371 
5000162487 
5000165134 
5000223800 
D200070532 
D200077396 
D200077727 
D200080051 
5000201749 
5000203596 
5000216036 
5000163410 
D200079111 
2700005520 
5000229476 



71 
57 
57 
58 
59 
74 
56 
65 
65 
74 
75 
76 
62 
63 
70 
74 
79 
79 
81 
68 
69 
70 
63 
80 
56 
71 



Report # page 
1650038430 82 



uu.ff Description Report # page 

03.30 bade code gen if local ptr to extrnl strcture is assgn vlu f rm extrn ary 5000221788 83 

- -0 



Product number uu.ff Description 



********none******** 64814 

64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 



CODE GENERATOR 



02.01 Incorrect code generated in FOR loop. 

02.01 The library routine, DISPOSE, overwrites the ES register 

03.01 functional type change of a constant into multi-byte structure gen's 

03.02 WITH construct causes wrong offset 
03.02 With construct causes wrong offset 

03.02 Unsigned 8 treated as signed value in FOR loop test. 

03.02 $RECURSIVE $ option defaults to incorrect mode (OFF) 

03.02 Pascal does not report error for assignment of constant to structure 

00.01 Stack POP'S exceed Stack PUSH'S when assignment made to ext var. 

01.10 Illegal PUSH instruction generated. 

02.00 Wrong code generated for expression in 'FOR' loop 



Report # page 

5000103432 85 

5000124313 86 

err D200063750 94 

D200068759 96 

D200068767 98 

D200075952 100 

D200077875 101 

D200079194 103 

1650018689 84 

D200023283 92 

5000118844 85 



Keyword index 



Keyword 

CODE GENERATOR 



Product number uu.ff Description 



PASCAL 
PASS 1 
RUN-TIME LIBRARY 



Keyword 



64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 



02.01 
02.01 
03.00 
03.00 
03.00 
03.00 
03.01 
03.01 
03.01 
03.01 
03.01 
03.03 
03.01 
03.02 
01.10 
01.10 



Using 

Incor 

Incor 

bad c 

Var. 

point 

Multi 

Code 

BX re 

Conte 

FOR 1 

Using 

for 1 

Funct 

Probl 

Real 



ES regi 
rect add 
rect cod 
ode for 
addresse 
ers pass 
plicat io 
produces 
gis t er g 
nts of r 
oop coun 

WITH st 
oop w/ c 
ional ty 
em wit h 
number c 



ster wi 
ress ca 
e gener 
acces s i 
s incor 
ed as p 
n resul 
an #11 
ets ove 
egister 
t e r get 
at ement 
ount er 
pe chan 
Pascal 
omparis 



thout i 
lculat e 
. when 
ng para 
rect i 
rocedur 
t store 
02 erro 
rw r i 1 1 e 

A gets 
s des t r 

and co 
= unsig 
ges not 
I/O lib 
ons may 

- -9 



nitalization - REP MOVSB. 

d for beginning of ary in WITH stamnt 

shift function operand is mult, dimen. array 

meters in nested procedures 

nside nested WITH statements 

e parameters not fully dereferenced. 

d in CX and overwritten when counter reg need 

r - reg. needed but not available 

n when accessing arrays of records 

overwritten when accessing mult, arrys of rd 
oyed when loop includes multiple WITH's 
mplex record structure causes bad code 
nd 8 type uses BX twice 

always evaluated correctly 
rary (PIOLIB). 

'evaluate' correctly. 



■ary 
not 



Product number uu.ff Description 



********none******** 64847 
CODE GENERATOR 64847 

64847 



00.46 In macros, "" and ' ' are not equivalent. 

00.00 Problem with negative displacementwi t h SBO SBZ instructions. 

00.46 Autoincrement with indirect addressing does not assemble correctly. 



Keywo rd 



Product number uu.ff Description 



********none******** 64286 
ENHANCEMENT 64286 

64286 
64286 



01.04 Answer to "Emulate SCR?" is automatically changed to "yes" 
01.03 Cannot single step through a Software Breakpoint 

01.03 MASK, STATUS, and IC are not always cleared when running from reset. 

01.04 Enhance the register display to show the Pending Interrupt Register 



Keywo rd 



Product number uu.ff Description 



********none******** 64882 

64882 
TRANSFER 64882 



01.20 VAX help on MAPBUS command causes system error 

01.70 64100 cluster disk free list is corrupted so there is not enough space 

02.00 CSIB process does not come up on system bootup 



Report # 


page 


1650004705 


84 


5000134817 


87 


5000138388 


87 


5000207845 


90 


D200053710 


93 


D200078642 


101 


5000163824 


88 


5000171876 


89 


5000171884 


89 


5000171900 


90 


D200065060 


94 


5000221994 


91 


5000197624 


90 


D200079251 


104 


D200019273 


92 


D200022137 


92 


Report # 


page 


D200035220 


105 


5000232959 


105 


5000121830 


105 


Report # 


page 


5000224022 


106 


5000164004 


106 


D200066357 


107 


D200068957 


107 


Report # 


page 



1650019257 108 
D200069104 108 
D200082669 108 



Keyword Product number uu.ff 

**Xc*****no ne******** 64883 01.00 



Desc ript ion 

Transfer does not handle imbedded linefeeds in binary files. 

- -0 



Keyword 



Product number uu.ff Description 



********none******** 648 8 

64880 



01.10 Invalid file names are not detected by the transfer utility. 
01.60 Debug file transfers may not function with 14 character file names 



Report # page 
D200082636 109 

Report # page 



D200019265 
1650018721 



111 
110 



Keyword index 



Keyword 
TRANSFER 



Product number 
64880 



uu.ff Description 

01.06 Bad file format does not cause error in transfer. 



Report # page 
5000219204 110 



Keywo rd 



Product number uu.ff Description 



Repo rt t* page 



********none******** 64100 

64100 
64100 
64100 
64100 
64100 
COPY 64100 

DC600 64100 

64100 



Keyword Product number 

********none******** 64285 

Keyword Product number 

#*******none******** 64851S001 

Keyword Product number 

********none******** 64851S003 



Keyword 



Product number 



********none******** 64274 

64274 
64274 



02.01 Formatting a floppy from a command file sometimes is unsuccessful. 

02.04 Comment is taken as a parameter when a null parameter is passed. 

02.06 Logical operators generate M0 error. 

02.07 Unique label is flagged as undefined in macro expansion. 
02.07 Instructions assembling differently than previous assembler. 
02.07 Phase error incorrectly reported on 64000 and hosted assemblers. 
02.01 "copy f:link_com to display" doesn't display all attributes of "f". 
00.01 64000 backup from 7946 to 9144 with 150' tape produces wrong message. 
02.04 No multi-tape backup strategy for discs > 64MB on the 64000. 

- -M 
uu.ff Description 

01.00 Inverse assembly for 1E91H is incorrectly shown as SUB *- , E, 

- -S 



uu.ff Description 
01.60 expressions 



of 



the form 123456.78 cause errors 

- -S 
uu.ff Description 

01.60 expressions of form 123456.78 cause errors 

- -S 
uu.ff Description 

01.04 Bad display of trace data with 8-bit UDE 

01.04 modify memory starting at odd addresses does not always work 

01.05 run until <addr> fails from reset when reset points to user code 



5000111666 
D200062604 
5000202770 
1650033209 
5000189985 
D200085050 
D200027953 
1650006908 
5000181552 



Report # 
5000223792 

Report # 
D200081620 

Report # 
D200081638 



112 
114 
113 
112 
113 
115 
114 
112 
113 



page 
116 

page 
117 

page 
118 



Report # page 



D200043828 
D200046623 
5000241562 



120 
120 
119 



Keyword 



Product number uu.ff Description 



*>Mc*****none******** 64808S004 

64808S004 
64808S004 
64808S004 
64808S004 

MENUS 64808S004 



01.20 Pmon flags a syntax error when attempting to append files 

01.20 User softkey display should be erased after shell escape. 

01.20 pwd truncates the /net/system portion of the path when RFA'ed to system. 

01.20 Pmon command completion intermit tant ly fails after completion error. 

01.20 Command search algorithm should match the softkey package. 

02.00 Pmon command completion via shell variables not working correctly 



Report # page 



1650036525 
D200077495 
D200080135 
D200080721 
D200081141 
1650038521 



121 
121 
122 
122 
122 
121 



Keyword index 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64824 

64824 
64824 
64824 
64824 
64824 
64824 
64824 
64824 
64824 
64824 
CODE GENERATOR 64824 
PASS 1 64824 



Keyword Product number 

********none******** 64824S004 



01.01 Incorrect transfer address when linking 9 or more files. 
01.03 Error using switch (*x++). 

01.03 RETI is not generated when exiting an interrupt procedure. 
01.03 Array is being placed in the PROG section rather than data. 

01.03 INT Multiplication of short by negative constant with SH0RT_ARITH. 

01.04 += operator does not work for pointers to structures. 

01.04 ZDconvert library module has two errors in the ZDdwordtoword routine. 

01.04 . 

01.04 +=, -=, *=, & /= may fail to auto vars with $RECURSIVE ON$ 

01.04 Warning message text is incorrect. 

01.04 MOD operation returning the wrong value. 

01.04 Floating point division of 2 constants generates incorrect result 

01.03 DIV, MOD and COMParisons may do unsigned estend of signed values 

- -8 
uu.ff Description 

01.20 Double word divide library returning incorrect result. 

- -8 



D2000 
50001 
50001 
50001 
D2000 
50002 
50002 
D2000 
D2000 
D2000 
D2000 
D2000 
D2000 



Keywo rd 



Product number uu.ff Description 



********none******** 64823 

64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
ADDR 64823 

PASS 1 64823 

PASS 2 64823 



Keyword Product number 

********none******** 64823S003 



01.03 
01.03 
01.03 
01.03 
01.03 
01.03 
01.03 
01.03 
01.03 
01.04 
01.04 
01.04 
01.04 
01.04 
01.03 
01.03 
01.01 



Unbe 

Libr 

FOR 

f unc 

Code 

Link 

Cert 

Func 

Pasc 

Code 

Bad 

Sign 

Unsi 

Comp 

ADDR 

Func 

Inco 



lieveabl 
aries re 
s t at emen 
tional t 

generat 
s not co 
ain vari 
tion Cal 
al does 

generat 
code gen 
ed_32 di 
gned_8 t 
ller may 
( x ) gene 
tional t 
rrect co 



e amount of library code 
ference procedures not a 
t with SIGNED_BYTE produ 
ype change of a constant 
ed by compiler increased 
rrectly established duri 
able accesses by nested 
Is via pointer may fail 
not report error for ass 
ed by compiler increased 
erated when CASE express 
vide returns wrong resul 
reated as signed value i 
confuse similar paramet 
rates incorrect code is 
ype changes not always e 
de generated when set el 

- -8 



linked for no-line program, 
ctually needed, 
ces incorrect code. 

into multi-byte structure gen's ei 

12% with latest version, 
ng calls of nested procedures, 
procedures may not work 

ignment of constant to structure 

12% with latest version, 
ion involves addition of two bytes 
t . 

n FOR loop test . 
ers in different subroutines 
x is of type BYTE, 
valuated correctly 
ements are passed as parameters. 



Keyword 



Product number 



********none******** 64820 

64820 



uu.ff Desc ript ion 

01.70 Nested external procedure call causes bad code to be generated. 

- -8 

uu.ff Description 

01.06 Array is being placed in the PROG section rather than data. 
01.06 Warning message text is incorrect. 



38778 
70654 
72825 
73278 
71373 
31605 
33866 
75044 
79079 
80374 
81471 
77222 
71431 



127 
124 
124 
125 
127 
125 
126 
128 
129 
130 
130 
129 
128 



Report # page 
5000226605 132 

Report # page 



50001 
50001 
50001 
D2000 
D2000 
D2000 
D2000 
D2000 
D2000 
50001 
50001 
50002 
D2000 
D2000 
50001 
D2000 
16500 



61000 
61034 
82014 
63875 
66761 
71332 
71340 
71423 
73031 
63287 
90629 
17927 
76067 
79301 
86742 
71365 
11585 



133 
134 
135 
137 
137 
138 
139 
140 
141 
134 
136 
136 
142 
143 
135 
139 
133 



Report # page 
5000224204 145 

Report tt page 



D200076760 
D200080341 



146 
147 



Keyword index 



Keyword 

CODE GENERATOR 
PASS 1 



Product number uu.ff Description 



64820 
64820 



01.06 Floating point division of 2 constants generates incorrect result 
01.03 DIV, MOD and COMParisons may do unsigned estend of signed values 



Report # page 



D200077107 
D200079137 



146 
146 



Keyword 



Product number uu.ff Description 



****)M»M:none******** 64816 

64816 
64816 

PASS 1 64816 



Report # page 



01.11 functional type change of a constant into multi-byte structure gen's err D200063834 



01.12 Unsigned_8 treated as signed value in FOR loop test 

01.12 Pascal does not report error for assignment of constant to structure 

01.12 Functional type changes not always evaluated correctly 



D200076026 
D200079210 
D200079277 



- -8 



Keyword 



Product number uu.ff Description 



149 
149 
150 
151 



Report ft page 



********none******** 64233 

64233 
64233 



01.07 Monitor displays wrong value for R15 and SSTK 5000137869 153 

02.00 User interrupts are not serviced for 17ms after analysis generated break 5000151431 153 
02.00 Can't find symbols loaded with more address bits than specified. D200071415 154 



SP.B detail reports as of 01/14/88 Page: 1 

Number: 1650038281 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

pwd truncates the /net/system portion of the path when RFA'ed to system. 

Problem: 

When using the HP 64000-UX products and netunaming across the LAN 
to another system, such as a compile server, the HP-UX command 
"pwd" which is used by the HP64000-UX product to tell what the 
local directory is, truncates the "/net/system" part of the path. 

This is a HP-UX operating system defect. It is not a defect in 

the HP 64000-UX application software. As soon as this defect is 

fixed in HP-UX, it will work correctly when using the HP 64000-UX 
applications. 

Signed off 01/14/88 in release Z01.80 

Number: 5000169474 Product: 64000-UX OP-ENV 300 64801S004 01.00 

One-line description: 

No error message given when opt run on memory board. 

Problem: 

64000 UX Options Test. 

No error or warning is given if a user tries to do options test on a 

memory board in the 64120 cardcage. The test for memory must be done 

through the memory controler board. The 64000 (classic) gives an error 

ERROR: No test availabe for selected card. 

The 64000-UX gives file not found error and the file 

/usr/hp64000/inst/pv/pv01f8 (for the 128k memory board). It looks 
for the board id number and puts "pv" in front of it for the file name 
it looks for. The user has no clue as to what is wrong. He only knows 
that file pv01f8 does not exist. 

Temporary solution: 

There are no performance verification tests available for memory 
boards. All memory boards are tested when the memory controller is 
tested. Do not select memory boards for testing within opt. 

Signed off 01/14/88 in release Z01.80 

Number: 5000185066 Product: 64000-UX OP-ENV 300 64801S004 01.00 

One-line description: 

Edbuild does not work whether invoked by the user or the emulator. 

Problem: 

About the EDBUILD Command fails. 

The customer system can not get response for the edbuild command, then 
a "load" command (in 8086 emulator mode) do not, either. 

-- THE CUSTOMER SYSTEM CONFIGURATION — 



SRB detail reports as of 01/14/88 Page: 



CPU - HP9000/320 

( The swap area - 10 Mbytes 
HP-UX rev. 5. 172 ) 



An absolute file name is sys.X ( sys.L, sys.K ). 
The program (sys.X) is large of 5_Mbytes on source. 
COMMANDS: 

edbuild sys, edbuild -h2 sys, edbuild -f Alist sys, edbuild -C sys 
edbuild -f Alist -h2 sys # All commands not response forever. 

Temporary solution: 

No workaround at this time. 

Signed off 01/14/88 in release Z01.80 

Number: D200076588 Product: 64000-UX OP-ENV 300 64801S004 01.50 

One-line description: 

If second card cage used in pv, it may not be released 

Problem: 

If second card cage used in pv, it may not be released. 

Problem: 

If a second card cage is needed to test a card (e.g., use 
a card in a second cage to test 1MB), if the second 
card is the last one allocated it may not be freed 
when option_test (opt) is exited. 

Workaround: 

After opt is finished, execute msunlock and msinit. 

Temporary solution: 

After opt is finished, execute msunlock and msinit. 

Signed off 01/14/88 in release Z01.80 

Number: D200076620 Product: 64000-UX OP-ENV 300 64801S004 01.50 

One-line description: 

Pressing return during a cycle command causes pv to hang 

Problem: 

When starting Performance verification, if the cycle softkey is 
pressed followed by the Return key, PV then says "Awaiting command" 
and the "stop" softkey is available, but the test is hung. 

Temporary solution: 

Do not press the return key after the "cycle" softkey. 
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Number: D200076679 Product: 64000-UX OP-ENV 300 64801S004 

One-line description: 

Msinit crashes opt test user. 



01.50 



Problem: 

msinit crashes another user's opt test. One user is in the opt test 
display, and does something ( anything that talks to the cage ). The 
other guy runs "msinit", and gets the message 'inconsistent module data, 
cleaning up'. When the opt test user then tries to do something, opt 
test is hosed. 

Temporary solution: 

Do not run msinit while any other user is running opt. 

Signed off 01/14/88 in release Z01.80 

Number: D200077G08 Product: 64000-UX OP-ENV 300 64801S004 01.50 

One-line description: 

If /usr/hp6400C/lock does not exist, msconfig gives odd messages. 

Problem: 
Text: 

if /usr/hp64000/lock does not exist, msconfig gives odd messages 

If, for some reason, the /usr/hp64000/lock directory is removed 
(which never happens unless the customer does so!), and if 
there were some measurement_systems defined prior to the lock 
directory being removed, the command 

remove_system <ar.ysys> 
gives a status message of 

"system <anysys> in use by ???" 

Temporary solution: 

As superuser, recreate the directory /usr/hp64000/lock with the 
command "mkdir /usr/hp64000/lock" . Then run msconfig again and 
remove the measurement system. 

Signed off 01/14/88 in release Z01.80 



Number: D200077941 Product: 64000-UX OP-ENV 300 64801S004 

One-line description: 

Msinit may autoconf igure incorrectly. 

Problem: 

Assume the following cards in the card cage: 

internal analyzer (wide or narrow) 

emulator #1 

state system (with EBPP) 
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When configuring with msinit, the user will be asked for an analyzer 
for emulator #1. If the internal analyzer is selected, msinit 
automatically configures the EBPP as the analyzer for emulator #2 
without asking any more questions This can be annoying if the state 
system is in fact connected to emulator #1. 

Temporary solution: 

Put the emulator without the analyzer (#2) in lower numbered 
slots. When msinit asks for the analyzer to be used, hit return 
to specify no analyzer. 

Signed off 01/14/88 in release Z01.80 

Number: D200077958 Product: 64000-UX OP-ENV 300 64801S004 01.00 

One-line description: 

HP enhancements are too slow to run softkeys. 

Problem: 

Softkeys track too slow on HP Terminals. Softkey lines are written 
out each time they change. Each time they are written, 400 characters 
are sent to the display; 80 for the contents of the line and another 
320 for the underlining enhancement. The extra characters result is 
very slow tracking because of all the 1/0. 

Temporary solution: 

All underlining can be turned off by creating a customized 

terminfo entry that does not have underlining capability. 

As Superuser, 

1) untie TERM >file #TERM is the value of the TERM variable for 

#that terminal 
2)Edit the file and a) replace the top line with an entry that uniquely 
identifies the new terminal type. The top line contains valid names 
that represent the characteristics defined in this file. 

Ex. 2392. Jdb, 

b) Remove the entry called "smul". 

3)Save the file. 

4)tic file. 

5) Set the TERM variable to the new terminal type. 
TERM*2392.Jdb 
export TERM 

Signed off 01/14/88 in release Z01.80 
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Number: D200079038 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

option_test multitest can't handle more than 24 cards 

Problem: 

When one attempts to do multitest, including all_cages, all_slots, 
the option_test software quits after configuring 24 cards (6 68020 
emulators). If each emulator is included separately, option_test 
will configure all 8 emulators, but it goes into the weeds during 
cycling of the test and reports multiple failures even though no 
low-level display show any failures. In addition, the low-level 
displays may show only 3 test completed while the main-level 
display reports thousands. 

Temporary solution: 

Do not test more than 24 boards at a time with multitest. 

Signed off 01/14/88 in release Z01.80 



Number: D200079095 Product: 64000-UX OP-ENV 300 64801S004 
One-line description: 

EDBUILD IS NOT WORKING PROPERLY 



01.60 



Problem: 

Edbuild runs much slower when a code segment is at a higher address than 

a Data segment. 

This problem is not really related to the segment type, but rather to 
the type of symbols in the segments. 

If the segments comprising a program are ordered such that one or ones 
containing no global symbols are loaded at the highest addresses 
in the program and there are no global symbols at higher addresses, 
edbuild will "forget" about the segment and all the symbol information 
within that segment. This leads to edbuild running faster because it 
is not processing all the symbol information. 

Note that when it runs faster in this case, edbuild is working 
incorrectly. 

Temporary solution: 

To make edbuild work correctly, add one or more global symbols to 

the segment at the highest address. 

Signed off 01/14/88 in release Z01.80 



Number: D200079293 Product: 64000-UX OP-ENV 300 64801S004 



01.70 



One-line description: 

Multiple <cr> after selecting card will leave softkeyw in an odd state. 

Problem: 
I f you 

1) select a card 

2) press carriage-return several times before the next screen 

- -4 
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displayed 

then 

the softkeys show the softkeys for the 'selection' mode, 
but the display shows the display for the test selected. 

WORKAROUND: 

don't hit return until the next display appears. 

Temporary solution: 

don't hit return until the next display appears. 

Signed off 01/14/88 in release Z01.80 

Number: D200079509 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 
Incompatible /etc/update programs. 

Problem: 

The version of /etc/update which is shipped with HP 64000-UX 
products is NOT compatible with the HP-UX version. This results 
in some rather unique problems when updates for the two types of 
products are to be loaded (i.e., "Cannot find table of contents"). 

Temporary solution: 

Unload the update tools each time a new update is performed. 
This will insure that a compatible /etc/update is used for 
the appropriate software. 

Signed off 01/14/88 in release Z01.80 

Number: D200080093 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

64000-UX processes do not die when modem carrier is lost. 

Problem: 

When in measurement system via a modem line connection, if the carrier 
is lost then the processes do not get killed. Yet the highest level 
process (your shell) goes away. This results in another getty being 
spawned on this line even though meas. sys. is still reading and writing 
to this port. 

Temporary solution: 

None exists at this time. 

Signed off 01/14/88 in release Z01.80 

Number: D200081984 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

Processes sometimes left running after parent has stopped. 

Problem: 

Sometimes, when the parent process to a measurement system is killed 

some of the measurement systems processes are left running. Please 
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change the behaviour of the products so that these processes die 
nicely. 



Temporary solution: 

If the tty associated with the process is a pty, then you can 

release the processes by 

cat < ptyxx 
This causes the pending output to be flushed, and the processes will die 
naturally. 



Signed off 01/14/88 in release Z01.80 



Number: D200078923 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

Search command files via "PATH" variable 

Problem: 

Allow search for command files using the PATH variable. 

Temporary solution: 

Command files must be specified with an absolute path or reside in 

the current working directory. 

Signed off 01/14/88 in release Z01.80 

Number: D200080101 Product: 64000-UX OP-ENV 300 64801S004 01.60 

Keywords: ENHANCEMENT 

One-line description: 

64000-UX uses TERMINF0 database only partially. 

Problem: 

64-UX software uses TERMINF0 database only partially. There 

is no description of the fact that it uses the TERMINFO database or the 

fact that it uses it in a way inconsistent with the definitions in 

section 4 of the HPUX reference manual. 

Signed off 01/14/88 in release Z01.80 
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One-line description: 

Nested IF stmnt. with bit field structure members genrate incorr. code 

Problem: 

The following program generates incorrect code: 

"6809" 

$SEPARATE 0N$ 
SRECURSIVE 0FF$ 
unsigned short e; 
unsigned short a; 
struct {unsigned d:2; 

unsigned short c:2;} b; 

QUAO 

{ if (b.c == 1) 

{if ((a~6)l I (e-«0)) 
{b.c=0;} } 
else 

{if ((a!=6)&&(e!=0)) 
b.c=0; 
} 
} 
main ( ) { } 

If the members of the structure are not bit fields then this problem 
does not occur. 

The problem occurs after the else statemnet. The code generated for 
the line "{if ( (a!-6)8A(e!-0) )" looks like: 

CLRB should be LDAB Dstatic+OOOOIH 

CMPB #006H 
BNE QUA01_11 
JMP QUA1_6 
QUA01_11 

should be LDAB Dstatic 
CMPB #000H 
BNE QUA01_12 
etc. 

Since the variables are not loaded into B the comparisons are meaningles 
s. 

Temporary solution: 

The following code might be used instead: 

{ if UB.C==1)&&((A==6)| I (E--0))) 

{B.C=0;} 
else 

{if l(B.C!«l)&&((A!-6)&ME!-0))) 
{B.C=0;} 

}} 
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Number: D200015073 Product: 6800 C 
Keywords: CODE GENERATOR 



64821 



01.04 



One-line description: 

Using a pointer dereference as an array index generates incorrect code. 

Problem: 

Given the following program, an incorrect "LDX ,X" is generated. 

"C" 

"6800" 

struct { 



struct { 



} 

short t; 
main () { 
t = p- 



short d; 
•p. 



short a; 
short b[5] ; 
} c; 



■c.b[ p->d ] ; 



After loading accumulator B with p->d by the "LDAB ,X" instruction, 
two subsequent loads of X are generated. 

LDX Dmain 

LDX ,X 
The "LDX ,X" is the incorrect instruction. 

Temporary solution: 
Define the structure as follows, 
struct { 

struct { 

short a; 
short b[5] ; 
} c; 
short d; 
} str; 
struct str *p; 
Then change the source line as follows for less and correct code, 
t = p -> c.b[ str.d ] ; 

Signed off 01/14/88 in release Z02.10 



Number: D200015347 Product: 6800 C 
Keywords: CODE GENERATOR 



64821 



01.04 



One-line description: 

Compiler doesn't reload register after value changes in a nested if expr 

Problem: 

In the following nested if expression, the compiler assumes the value of 

register D has not changed when it makes the comparison of test to 

0X01. 

- -8 
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"C" 

"6800" 

int test=0x0040; 

main ( ) { 

if ( test & OxffOO) { 
if ( test & 0x01 ); 
} 
} 

Register D is initially loaded with the value of test, anded with OxffOO 
and then set equal to the result of the and. The code for the next if 
begins by anding the D register with 0x01 before reloading D with the 
value of test. 

Temporary solution: 

Turn $AMNESIA 0N$ before second if statement. 

Signed off 01/14/88 in release Z02.10 



Number: D200067629 Product: 6800 C 



64821 



01.06 



One-line description: 

Assigning to bitfield causes entire structure to be reset. 

Problem: 

If you have a static structure containing bit fields and you 

set one of the members to the entire structure is reset. 



"C" 
"6800" 






unsigned int 


i; 


struct { 




unsigned 


one 




unsigned 


two 




unsigned 


three 




unsigned 


four 




unsigned 


five 




unsigned 


six 




unsigned 


seven 




unsigned 


eight 




} bit_struct; 




mainO { 







bit_struct. f ive - 0x01; 
bit_struct. eight ■ 0x00; 



} 



/* entire structure is reset. */ 



Temporary solution: 

The only known work around at this time is to declare a local 
(automatic) structure of the same type as the external. Upon 
entering a function equate the two structures and do this 
again just before the function is exited. This will cause 
excessive code generation. 

Signed off 01/14/88 in release Z02.10 

- -8 
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Number: D200076302 Product: 6800 C 64821 01.07 


Problem: 






Conditionals that emploj 


div, mod, or comparison operations ma> 


not 


One-line description: 


correctly extend signed 


short values to int size if the other c 


perand 


Array is being placed in the PROG section rather than data. 


is an unsigned short or 


char. For example, in the following code s 




is extended as if it were declared an unsigned short. 




Problem: 








Compiler puts array that should be in DATA section in PROG section 








Example: 

"C" 
"Z80" 


$SH0RT_ARITH 0FF$ 






short s; 






char array [ 12] ; 


unsigned short us; 






The above code when compiled creates an array of twelve bytes that will 


main( ) 






reside in the PROG section. This should be placed in the DATA section. 


{ 








if ((s/usroxffff) 


/* both s and us get unsigned extend 


*/ 


Temporary solution: 


error ( ) : 
if ((us%s) 0x007f) 






Generate an ASM_FILE and edit the ASMProcessor file to place 


/* both s and us get unsigned extend 


*/ 


the array under the DATA counter. 


error! ) 










if (us==s) 




/* both s and us get unsigned extend 


*/ 


Signed off 01/14/88 in release Z02.10 


error ( ) 










if (s!=us) 
error! ) 




/* both s and us get unsigned extend 


*/ 


Number: D200077149 Product: 6800 C 64821 01.07 






if (s<us) 




/* both s and us get unsigned extend 


*/ 


Keywords: CODE GENERATOR 


errort ) 










if (s>us) 




/* both s and us get unsigned extend 


*/ 


One-line description: 


error! ) 








Floating point division of 2 constants generates incorrect result 


} 






Problem: 


Signed off 01/14/88 in 


-elease Z02.10 




Compiler generates incorrect code for evaluation of double division: 








"C" 


Number: D200080358 Product: 5800 C 64821 


01.07 


"8088" 








main! ) 


One-line description: 






{ 


Warning message text is 


incorrect. 




double xx ; 








XX ' 2.0/3.0; 


Problem: 






xx = 2.0; 
xx is assigned the value 2.0 by both statements. 


68000 C compiler, Just updated to 2.07. 




Warning 521: Unsigned integer to real conversion treated as signed. 




Is incorrect. 









This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx = 2.0/y; where y = 3.0; 

Signed off 01/14/88 in release Z02.10 



Number: D200079145 Product: 6800 C 
Keywords: PASS 1 



64821 



01.07 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 



The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 
•■C" 

"68000" 

unsigned int a; 

main!) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

- -8 
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$WARN OFF$. This will turn off all warning messages. 
Signed off 01/14/88 in release Z02.10 
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64811 



14 
01.08 



One-line description: 

Generates bad code for parameter as ADDR of component. 

Problem: 
"6800" 

{ PascBug25: Pascal generates bad code for parameter as ADDR of 
component. 

Pascal is generating bad code if a parameter passed to a pro- 
cedure is the address of the first element of a record, and that 
record is specified in a WITH statement. 

The compiler is erroniously generating an indirect flag preceding 
the parameter specifier in the calling sequence. 

To observe the bad code, try: 

"compile PascBug25 listfile printer options expand" } 

PROGRAM PascBug25; 

TYPE PTR - "INTEGER; 

VAR V: RECORD 

element_l: INTEGER; 
element_2: INTEGER; 
END; 

PROCEDURE proc (pointer: PTR); EXTERNAL; 

BEGIN 

WITH V DO 
BEGIN 

proc (ADDR (element_l) ) ; {bad code - addr passed with indirection} 
proc (ADDR (element_2)i {good code} 
END 
END. 

Temporary solution: 

Avoid use of "WITH" statement. 

Signed off 01/14/88 in release Z01.90 



Number: D200063123 Product: 6800 PASCAL 



64811 



01.10 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 
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"processor" 
PROGRAM BAD_DATA; 
TYPE EVENT = RECORD 
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A 
B 
C 
D 
END; 



BYTE; 
BYTE; 
INTEGER; 
BYTE; 



VAR EVENT 1 : EVENT; 



PROCEDURE GENERATORt ); 
BEGIN 

EVENT 1 := EVENT (0) : 
END; 

BEGIN 
END. 

Temporary solution: 
No temporary solution. 



{ THIS ASSIGNMENT RESULTS IN BAD DATA } 



Signed off 01/14/88 in release Z01.90 



Number: D200075861 Product: 6800 PASCAL 



64811 



01.20 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

SEXTENSI0NS 0N$ 

PROGRAM D0LO0P; 



VAR SECTORNUM,STOPSECTOR 
A 



: UNSIGNED_8; 
: INTEGER; 



BEGIN 

ST0PSECT0R := UNSIGNED_8(247); 

FOR SECTORNUM := UNSIGNED_8 (0 ) TO STOPSECTOR DO BEGIN 

A := 5; 

END; 
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END. 

Temporary solution: 

USE AN UNSIGNED 16 FOR THE CONTROLLING VAR. 



"PROCESSOR" 
$EXTENSIONS 0N$ 
PROGRAM D0L00P; 
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VAR SECTORNUM, STOPSECTOR 
A 



UNSIGNED_16; 
INTEGER; 



BEGIN 



END. 



STOPSECTOR := UNSIGNED_16(247) ; 

FOR SECTORNUM := UNSIGNED_16 (0 ) TO STOPSECTOR DO BEGIN 

A := 5; 
END; 



This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.90 



Number: D200079178 Product: 6800 PASCAL 



64811 



01.20 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 

changes physical size), when it should generate a fatal error. It 

tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 



- -8 
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■•PASCAL" PREPROCESS 

"6809" 

{ Test program to demonstrate Pascal language defect } 

{ Functional type change of constant to multi-byte variable > 

PROGRAM PTEST101; 



EXTENSIONS ON$ 




TYPE event = RECORD 




type : 


BYTE; 


cualif ier: 


BYTE; 


n.sg : 


INTEGER; 


send task: 


BYTE; 


END; 




VAR event 1: event; 




i: INTEGER; 




R: REAL; 





BEGIN 

{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 



eventl 



event(O); {This code is incorrect Pascal} 



{Correct Pascal using individual assignments} 

eventl. type: =0; 

event 1. qual i f ier: =0; 

eventl. msg:=0; 

event 1 send_task : =0 ; 
END. 



Signed off 01/14/88 in release Z01.90 



Number: D200079236 Product: 6800 PASCAL 
Keywords: PASS 1 



64811 



01.20 
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BEGIN 
U16 
U16 



UNSIGNED_16(S8): 
UNSIGNED_8(S8); 



END. 



S16 := SIGNED_16(U8) 
S16 := SIGNED 8(U8); 



(* signed extension of S8 - correct *) 

(* signed extension of S8 - incorrect *) 

(* unsigned extension of U8 - correct *) 

(* unsigned extention of U8 - incorrect ■ 



Signed off 01/14/88 in release Z01.90 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



$EXTENSI0NS 0N$ 
FR0GRAM PTEST; 

VAR 



S8 


SIGNED 8 ; 


U8 


UNSIGNED 8 


S16 


SIGNED 16 ; 


U16 


UNSIGNED 16 



- -8 
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Number: D200061556 Product: 68000 ASSEMB 64845 

One-line description: 

EOU is not working with DC correctly. 

Problem: 

The EQU pseudo when used with the DC psuedo causes incorrect 

object code to be generated. 

"68000" 



; VALUE IS 6 
; VALUE IS 5 



Temporary solution: 

No temporary solution known at this time. 



19 
01.10 



X 


EQU 


7 




DC.B 


X 


X 


SET 


X-l 




DC.B 


X 



Signed off 01/14/ 



in release Z02. 10 
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Number: 1650026583 Product: 68000 C 64819 

One-line description: 
Invalid error 60 flagged. 

Problem: 

When multiple assignments which include a function call are made 

on a single line error 60 is incorrectly flagged. 

"C" 
"processor" 

extern int *func( ) ; 

main() { 

int *xptr; 
char *cptr; 

cptr = (char *)xptr = funcO; 

} 

Temporary solution: 

Break the assignment across two lines. 

"C" 
"processor" 

extern int *func(); 

main! ) 
{ 

char *cptr; 
int *xptr; 

xptr - funct ) ; 

cptr - (char *)xptr; 
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01. 10 



} 

Signed off 01/14/88 in release Z02.10 



Number: 5000171124 Product: 68000 C 



64819 



01.09 



One-line description: 

Result is invalid if terenary expression evaluates to false. 

Problem: 

Incorrect code is generated when the result from a conditional 

statement is false. 

"C" 

"68000" 

struct s_type { 

int fieldl; 

- -8 
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int field2; } ; 

extern int my_funct(); 

int test(sp) 
struct s_type *sp; 

{ int loc_var = 0; 

sp -> field2 = ( loc var ? my functO : ); 
> 

mainO {} 

The expanded code for the above program demonstrates the problem. 
The offset into the the structure is calculated only for the 
true condition. If a false condition is the result the program 
jumps before it calculates the offset. 

Temporary solution: 

Replace the terenary expression with an equivalent if-then-else. 

Signed off 01/14/88 in release Z02.10 



Number: 5000183839 Product: 68000 C 64819 

One-line description: 

$LIST 0N/0FF$ doesn't work correctly. 

Problem: 

SLIST ON$ and $LIST 0FF$ directives not working properly. 

For Example: 

"68000" 

SLIST 0FF$ 

/* comment 1 off */ 

$LIST 0N$ 

/* comment 1 on */ 

ma int ) 

{} 

When compiled with the output option creates: 

"C" 

"68000" 

$LIST 0FF$ 

/* comment 1 off */ 

$LIST 0N$ 

/* comment 1 on */ 

Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z02.10 



- -8 



01. 10 
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Number: 5000204586 Product: 68000 C 



Page: 
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22 
01. 10 



One-line description: 

Wrong floating point value assigned in a terenary expression. 



Problem: 

64000 - UX C Compiler rev. 1.1 

Incorrect value generated when: 

"C" 

"68000" 

$FAR$ 

$CAL_ABS_LONG$ 

$LIB_ABS_L0NG$ 

float testl, testlO; 

float resultl, result2, result3, result4; 

mainO { 

float number • 10; 

float num = 1; 

testl = 1; 

testlO = 10; 

resultl = (testl>2)?number:num; 

result2 = ( test 1 >2 ) ?(number+0 ): (num+0) ; 

result3 = ( testl<2) ?number;num; 

result4 = (testl<2)?(number+0) : (num+0) ; 

Signed off 01/14/88 in release Z02.10 



resultl should = result2 but doe 
sn't. when the var name is alone 
without ( +#) the results are 
odd. The same thing happens for 
choosing the "TRUE" value. 



-resultl = 3c000000h = 1/128 

-result2 = 3f800000h = 1.0 OK! 

-result3 = 49000000h = 2**19 

}-result4 = 41200000h - 10 OK! 



Number: 5000206649 Product: 68000 C 



64819 



01.09 



One-line description: 

Two external declarations are made for one function. 

Problem: 

Compiler makes double external symbols. 

Example 

fl() 

{ extern f ( ) ; 



} 

f2() 

{ extern f ( ) ; 



} 

Compile this file, make 

EXTERNAL F 

EXTERNAL F 

Temporary solution: 

The file will still link with no errors so you can ignore the 
problem. Or pull the declaration of "extern f()" outside 
of the procedures which reference f() ( in other words make 
the declaration at the top of your source file.) 

Signed off 01/14/88 in release Z02.10 



SRB detail reports as of 01/14/88 
Number: 5000223099 Product: 68000 C 
Keywords: ENHANCEMENT 



64819 
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01.90 



One-line description: 

Generate XREF from compiler which is readable by EDT. 

Problem: 

Antoinette Burkett sc: 

Generate a listing with cross references from a C compiler program 
on the VAX. When editing that file using edt an error message will 
be encountered : error reading from input file filename : file 
specification /irms-w-rtb 512 byte record too large for users 
buffer, press return to continue. The edt editor will then show 
all parts of the file except the xref. 

Signed off 01/14/88 in release Z02.10 



Number: 5000234237 Product: 68000 C 



64819 



01.02 



One-line description: 

68008 libraries cause target processor disagree errors. 

Problem: 

Linker gives error message : target processors disagree file 

/usr/hp64000/lib/clib/168008/real_lib.R ! 

Signed off 01/14/88 in release Z02.10 



Number: D200014340 Product: 68000 C 
Keywords: CODE GENERATOR 



64819 



01.07 



One-line description: 

Bad code using $RANGE$ or $DEBUG$ with $CALL_PC_LONG$ or $LIB_PC_L0NG$ 

Problem: 

Bad code is generated when calling functions and the compiler 
directives SRANGE 0N$ or $DEBUG 0N$ are used in combination with 
the directives $CALL_PC_LONG$ or $LIB_PC_L0NG$. For example, 

SDEEUG ON, LIB_PC_LONG$ int i; 

int f ( ) { return 0; } 

main() { i = f() * 2; /* Produces bad code */ 



BSR F 
MULS #2,D7 
M0VE.L D7,-[A7] 



CALL F 

MULTIPLY RESULT IN D7 TIMES 2 
PUSH PARAMETER FOR Zoverf low_sl6 
M0VE.L #Zoverflow_sl6[PC] ,D7 ;ERR0R!! D7 DESTROYED! ! 
JSR -6[PC,D7.L] ;CALL Zoverf low_sl6 VIA PC LONG METHOD 
M0VE.W D7,I ;WR0NG VALUE STORED, D7 CONTAINS BAD DATA!! 

Temporary solution: 

Avoid the combination of functions, $RANGE$ or $DEBUG$, and 
$CALL_PC_LONG$ or $LIB_PC__L0NG$. The example above may be rewritten 
to achieve the same functionality. 



- -8 
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i = f(); /*STATEMENT DOES NOT CAUSE CALL TO OVERFLOW ROUTINE*/ 

i = i * 2; /*0VERFL0W ROUTINE CALLED HERE BUT DATA IS NOT IN D7*/ 

Signed off 01/14/88 in release Z02.10 



Number: D200069666 Product: 68000 C 



64819 



01.09 



One-line description: 

Compiler aborts when it encounters a legal structure declaration. 

Problem: 

The compiler aborts for a legal structure declaration. 

"C" 
"processor" 

structure tag { int varl; } A; 

mainO { 

A. varl = 1; 

} 

The compiler allocates 110H bytes of storage and then aborts. 



Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z02.10 

Number: D200077065 Product: 68000 C 

Keywords: CODE GENERATOR 



64819 



01.10 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

■•C" 

"8088" 

main() 

{ 

double xx ; 

XX - 2.0/3.0; 

xx = 2.0; 
} 
xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 



Temporary solution: 



-8 
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xx - 2.0/y; where y = 3.0; 
Signed off 01/14/88 in release Z02.10 
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Number: D200079129 Product: $8000 C 
Keywords: PASS 1 



64819 



01.10 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 

Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SH0RT_ARITH 0FF$ 

short s; 

unsigned short us; 



main( ) 
{ 

if 



( (s/usPOxffff ) 

error ( ) : 
if Uus'/.s) 0x007f) 

error ( ) ; 
if (us==s) 

error( ) 

(s! =us) 

error ( ) 

(s<us) 

error ( ) 
if (s>us) 

error ( ) 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z02.10 
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Number: 1650009456 Product: 68000 PASCAL 64815 

One-line description: 

System reboot for syntax error. 

Problem: 

The following program will cause the 64000 station to reboot. 

"68000" 

PROGRAM TASK4; 
PROCEDURE TEST1; 



26 
00.01 



VAR 



REAL; 
BOOLEAN; 



BEGIN 

IF X>0.0 
IF X<0.0 
END; 



THEN 
THEN 



A :- FALSE 
A := FALSE 



{MISSING SEMI-COLON CAUSES PROBLEM} 
{THIS IF IS ALSO NEEDED. } 



Temporary solution: 

If the 64000 station reboots during a compilation check your code 

for this type of syntax error. 

Signed off 01/14/88 in release Z01.90 



Number: 1650019224 Product: 68000 PASCAL 



64815 



01. 1C 



One-line description: 

Incorrect code generated for array which has boolean indices. 

Problem: 

Using boolean values as indices to an array will cause an incorrect 

offset to be generated. 

"68000" 

PROGRAM bool; 
SEXTENSI0NS 0N$ 

VAR arr : ARRAY [1. .4, BOOLEAN] OF BYTE; 
j : BOOLEAN; 



BEGIN 

j := FALSE; 
arrtl.j] := 1; 
arr[2,j] := 1; 



END. 



{ This is OK } 

{ offset is calculated incorrectly 
(200H + j). } 



Temporary solution: 

Use an indice of type integer rather than boolean. 

"68000" 



SRB detail reports as of 01/14/88 



$EXTENSI0NS 0N$ 

CONST TRUE = 1; 
FALSE = 0; 

VAR arr : ARRAY [1. .4,0 .. 1] OF BYTE; 
j : INTEGER; 

BEGIN 

j := FALSE; 

arr[2,j] :=1; 
END. 

Signed off 01/14/88 in release Z01.90 
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Number: 1650019331 Product: 68000 PASCAL 



64815 



01.10 



One-line description: 

Set manipulation results in incorrect code being generated. 

Problem: 

The compiler appears to miss a syntax error and instead generates 

bad code. 

"68000" 
SEXTENSIONS 0N$ 



PROGRAM set_test; 

TYPE set_values 
set_type 

SEXTVAR 0N$ 

VAR operation 

x,y,z 

set_var 

values 
iEXTVAR 0FF$ 



0. .32; 

SET OF set values; 



set member 



BYTE; 

INTEGER; 

set_type; 
set values; 



INTEGER; 



BEGIN 



set_member 
set var 



:= 04; 

:= set_type [set_member] ; 



{ I believe the customer wants to type cast set_member and therefore 
should use '()'. The compiler generates code to clear a 5 byte 
block beginning at the address of the variable operation. } 

END. 

Temporary solution: 

No temporary solution at this time. 



- -8 
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Number: D200063792 Product: 68000 PASCAL 



64815 



01.11 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 

"processor" 

PROGRAM BAD_DATA; 

TYPE EVENT = RECORD 



A 


BYTE; 


B 


BYTE; 


C 


INTEGER 


D 


BYTE; 


END; 





VAR EVENT 1 : EVENT; 



PROCEDURE GENERATOR ( ) ; 
BEGIN 

EVENT1 : = EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA } 
END; 

BEGIN 
END. 

Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z01.90 



Number: D200079202 Product: 68000 PASCAL 



64815 



01. 12 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 
changes physical size), when it should generate a fatal error. It 
tries to generate code for the illegal statement which will not 
produce the results expected by the user. 
The compiler should produce fatal Error #451: Structured constants not 

- -8 
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Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPROCESS 
"6809" 

{ Test program to demonstrate Pascal language defect } 
{ Functional type change of constant to multi-byte variable } 
PROGRAM PTEST101; 
SEXTENSIONS 0N$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR event 1: event; 
i: INTEGER; 
R: REAL; 

BEGIN 

{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 

eventl := event (0); {This code is incorrect Pascal} 



{Correct Pascal using individual assignments} 

eventl. type: =0; 

eventl .qualifier: =0; 

eventl. msg: =0; 

eventl . send_task : =0 ; 
END. 



Signed off 01/14/88 in release Z01.90 
Number: D200079269 Product: 68000 PASCAL 
Keywords: PASS 1 



64815 



01.12 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



$EXTENSIONS 0N$ 
PROGRAM PTEST; 
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VAR 



S8 
U8 
S16 
U16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



BEGIN 

U16 := UNSIGNED_16(S8); 
U16 := UNSIGNED_8(S8); 



(* signed extension of S8 
(* signed extension of S8 



correct *] 
incorrect *) 



S16 
S16 



END. 



SIGNED_16(U8); 
SIGNED_8(U8); 



(* unsigned extension of U8 - correct *) 
(* unsigned extention of U8 - incorrect 



Signed off 01/14/88 in release Z01.90 



SRB detail reports as of 01/14/88 
Number: D200076844 Product: 6809 C 



Page: 31 
64822 01. 0E 



One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 

"C" 

"Z80" 

char array [ 12] ; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASM_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 01/14/88 in release Z01.80 



Number: D200 077180 Product: 6809 C 
Keywords: CODE GENERATOR 



64822 



01.08 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main! ) 

{ 

double xx; 

xx = 2.0/3.0; 

xx = 2.0 ; 
} 
xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 



Temporary solution: 

xx - 2.0/y; where y 



3.0; 



Signed off 01/14/88 in release Z01.80 



Number: D200079152 Product: 6809 C 
Keywords: PASS 1 



64822 



01.08 



One-line description: 

oiv, MOD and COMParisons may do unsigned estend of signed values 
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Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SHORT_ARITH 0FF$ 



short s; 

unsigned short us; 



main! 
{ 



} 



if ( (s/usPOxffff ) 

error ( ) : 
if UusXs) 0x007f) 

error ( ) ; 
if (us==s) 

error! ) 
if (s!=us) 

error( ) ; 
if (s<us) 

errort ) 
if (s>us) 

errort ) 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z01.80 



Number: D200080366 Product: 6809 C 64822 01.08 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 

•■C" 

"68000" 

unsigned int a; 

main!) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 



SRB detail reports as of 01/14/88 
Signed off 01/14/88 in release Z01.80 
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One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 

"processor" 

PROGRAM BAD_DATA; 



TYPE 


EVENT « 


■ RECORD 




A 


BYTE; 




B 


BYTE; 




C 


INTEGER; 




D 


BYTE; 




END; 





VAR EVENT 1 



EVENT ; 



PROCEDURE GENERATOR ( ) ; 
BEGIN 

EVENT1 :- EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA ) 
END; 

BEGIN 
END. 



Temporary solution: 
No temporary solution. 

Signed off 01/14/88 in release 201.60 



Number: D200075911 Product: 6809 PASCAL 



64813 



01. 11 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 



Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

$EXTENSIONS 0N$ 

PROGRAM D0L00P; 



VAR 



SECTORNUM.STOPSECTOR 
A 



INTEGER; 
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tries to generate code for the illegal statement which will not 


BEGIN 








produce the results expected by the user. 


ST0PSECTOR := UNSIGNED_8(247) ; 








The compiler should produce fatal Error #451: Structured constants not 
implemented. 


FOR SECTORNUM := UNSIGNED_8 (0 ) TO STOPSECTOR 


DO 


BEGIN 














Here is a simple example and the workaround by explicit individual 


A :- 5; 








assignment statements. 


END; 








"PASCAL" PREPROCESS 


END. 








"6809" 

{ Test program to demonstrate Pascal language defect } 


Temporary solution: 








{ Functional type change of constant to multi-byte variable } 


USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 








PROGRAM PTEST101; 










$EXTENSIONS ON$ 
TYPE event = RECORD 


"PROCESSOR" 








type 
qualifier 


BYTE; 
BYTE; 


SEXTENSIONS 0N$ 








msg 

send task 


INTEGER; 
BYTE; 


PROGRAM DOLOOP; 








END; 
VAR event 1: event; 


VAR SECTORNUM, STOPSECTOR : UNSIGNED 16; 








i: INTEGER; 


A : INTEGER; 








R: REAL; 
BEGIN 


BEGIN 








{The following code is attempting to initialize} 


STOPSECTOR : = UNSIGNED_16(247) ; 








{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 


FOR SECTORNUM := UNSIGNED_16 (0 ) TO STOPSECTOR DC 


BEGIN 




{ Error #451: Structured constants not implemented} 


A :- 5; 
END; 








{ The code produced will be processor dependent } 








eventl := event(O); {This code is incorrect Pascal} 


END. 








{Correct Pascal using individual assignments} 


This works for values up to 8000H. 








eventl. type: =0; 
event l.qualif ier:-0; 


Signed off 01/14/88 in release Z01.60 








eventl. msg: =0; 
eventl. send task:=0; 


Number: D200079186 Product: 6809 PASCAL 


64813 


01.11 


END. 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 
changes physical size), when it should generate a fatal error. It 



Signed off 01/14/88 in release Z01.60 



Number: D200079244 Product: 6809 PASCAL 
Keywords: PASS 1 



64813 



01. 11 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 
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Number: D200068825 Product: 80286B ASSEMB 64859 01.02 


$EXTENSI0NS ON$ 








PROGRAM PTEST; 






One-line description: 

Assembling on 64100 & linking on VAX generates erroneous absolute file 


VAR 








S8 


SIGNED 8 ; 






Problem: 


U8 


UNSIGNED 8 ; 






If all programs are assembled and linked on the VAX and then downloaded 


S16 


SIGNED 16 ; 






to the 64100, the execution in the emulator is fine. But if the monitor 


U16 


UNSIGNED 16 ; 






is assembled on the 64100 and uploaded where it is linked on the VAX and 








downloded back to the 64100, the program runs off in the weeds. 


BEGIN 








U16 : = UNSIGNED 16 (S8) ; 


(* signed extension of S8 - 


correct *) 


Temporary solution: 


U16 := UNSIGNED_8(S8); 


(* signed extension of S8 - 


incorrect *) 


There is no known work around at this time. 


S16 : = SIGNED 16(U8) ; 


(* unsigned extension of U8 


- correct *) 


Signed off 01/14/88 in release Z01.30 


S16 := SIGNED 8(U8); 


(* unsigned extention of U8 


- incorrect *) 




END. 




Signed off 01/14/88 in release Z01.60 

















-0 
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Number: D200063909 Product: 8085 B PASCAL 64825 


01 


.03 


PROCEDURE Init Set; 
BEGIN 


One-line description: 






Letters Pas([]); (*Code generates an extra INC SP after the 


functional type change of a constant into multi-byte structure gen 


s 


srr 


END; call to Letters Pas*) 
SGLOBPROC 0FF$ 


Problem: 








Functional type casting of a constant into a multi-byte structure 








generates bad data. 






Temporary solution: 

Any set size other than 3 bytes will work correctly. 


"processor" 






Signed off 01/14/88 in release Z01.90 


PROGRAM BAD_DATA; 










Number: D200076109 Product: 8085 B PASCAL 64825 01.04 


TYPE EVENT = RECORD 








A 


BYTE; 






One-line description: 


B 


BYTE; 






Unsigned_8 treated as signed value in FOR loop test. 


C 


INTEGER; 








D 


BYTE; 






Problem: 


END; 






Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 


VAR EVENT 1 : EVENT; 






it is treated as a signed value. In the example below, an unsigned 8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 


PROCEDURE GENERATOR! ); 






unsigned_8 as a signed quantity. 


BEGIN 








EVENT1 := EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA } 






"processor" 


END; 






SEXTENSIONS 0N$ 


BEGIN 








END. 






PROGRAM DOLOOP; 


Temporary solution: 






VAR SECT0RNUM.ST0PSECT0R : UNSIGNED 8; 


No temporary 


solution at this time. 






A : INTEGER; 



Signed off 01/14/88 in release Z01.90 


BEGIN 

ST0PSECTOR := UNSIGNED 8(247); 


Number: D200064212 Product: 8085 B PASCAL 64825 01.03 
Keywords: PASS 2 


FOR SECT0RNUM := UNSIGNED_8(0) TO ST0PSECT0R DO BEGIN 
A := 5; 


One-line description: 

Incorrect code generated when set elements are passed as parameters. 


END; 


Problem: 

Incorrect code is generated when sets are passed as parameters. 
The stack pointer is manipulated so that the program "goes in the 
weeds" after the call to the procedure. The following code is 
an example: 


END. 

Temporary solution: 

USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 


"processor name" 
SSEPARATE 0N$ 
SEXTENSIONS 0N$ 
TYPE 

Letters « (a,b,c,d,e, f ,g,h, i, j,k, l,m,n,o,r) ; 

Set of Letters = SET OF Letters; 
SGLOBPROC ON$ 
PROCEDURE Letters_Pas(Received:Set_of_Letters) :EXTERNAL; 


"PROCESSOR" 

SEXTENSIONS 0N$ 

PROGRAM DOLOOP; 

VAR SECTORNUM.STOPSECTOR : UNSIGNED 16; 
A : INTEGER; 


- -0 


- -0 
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BEGIN 



STOPSECTOR := UNSIGNED_16(247) ; 

FOR SECTORNUM := UNSIGNED_16(0 ) TO STOPSECTOR DO BEGIN 

A : = 5; 
END; 
END. 

This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.90 



Number: D200079228 Product: 8085 B PASCAL 



64825 



01.04 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Froblem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is nc meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 

changes physical size), when it should generate a fatal error. It 

tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPROCESS 

"6809" 

{ Test program to demonstrate Pascal language defect } 

{ Functional type change of constant to multi-byte variable } 

PROGRAM PTEST101; 



IEXTENSIONS 0N$ 




TYPE event = RECORD 




type 


BYTE; 


qualifier 


BYTE; 


msg 


INTEGER 


send task 


BYTE; 


END; 




VAR eventl: event; 




i: INTEGER; 




R: REAL; 





SRB detail reports as of 01/14/88 



BEGIN 

{The following code is attempting to initialize) 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 
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eventl := event(O) 



{This code is incorrect Pascal) 



{Correct Pascal using individual assignments} 

eventl. type: =0 ; 

eventl. qualifier: *0 ; 

eventl. msg: =0 ; 

eventl . send_task : »0 ; 
END. 



Signed off 01/14/88 in release Z01.90 



Number: D200079285 Product: 8085 B PASCAL 
Keywords: PASS 1 



64825 



01.04 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



$EXTENSI0NS 0N$ 
PROGRAM PTEST; 



VAR 



S8 
U8 
S16 
U16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



BEGIN 

U16 := UNSIGNED_16(S8) 
U16 := UNSIGNED 8(S8) ; 



(* signed extension of S8 - correct *) 
(* signed extension of S8 - incorrect *) 



END. 



S16 : = SIGNED_16(U8) 
S16 := SIGNED 8(U8): 



unsigned extension of U8 
unsigned extention of U8 



correct *) 
incorrect *) 



Signed off 01/14/88 in release Z01.90 



SRB detail reports as of 01/14/88 
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Number: 5000172742 Product: 8085 C 


64826 


01.03 












Problem: 


Keywords. 


CODE GENERATOR 






Unnecessary warning message is given when subtracting an integer from 
a pointer. 


One-line 


description: 








bad code 


generated with *pointer++ operation 






Example: 


Problem: 








"C" 


The example provided produces the following code: 






"8085" 


*b++ - *c++; 






unsigned short var,*ptr; 


LXI 


H.00002H 






main( ) 


DAD 


SP 






{ 


MOV 


E,M 






var=(*(ptr - 1) ); 


I NX 


H 






} 


MOV 


D,M 






this generates an unnessary message about the pointer and the integer 


XCHG 








not being the same size 


SHLD 


Dfunc+0002H 








I NX 


H 






Temporary solution: 


XCHG 








A workaround is to add a negative integer and no warning message will 


LXI 


H.00002H 






be generated. Example var=(*(ptr + -1)). 


DAD 


SP /* HL = SP+2 */ 








MOV 


M,E <--puts address of what b points 


to + 1 in 




Signed off 01/14/88 in release Z02.10 


I NX 


H < 1 address of b, instead of 

M,D < — 1 


*b++ 






MOV 


Number: D200068403 Product: 8085 C 64826 01.03 


LHLD 


Dfunc 






One-line description: 

Expression used as array index generates incorrect code. 



Temporary solution: 


Problem: 


Use $RECURSIVE 0N$ directive, or increment the pointer in a seperate 


Incorrect code is generated if an array index is an expression of 


operation 


the form [i+1] for example. The following program demonstrates 




the problem: 


Signed off 01/14/88 in release Z02.10 


"C" 

"8085" 




Number: 5000202846 Product: 8085 C 64826 01.04 


SRECURSIVE 0FF$ 




$SEPARATE ON$ 


Keywords: CODE GENERATOR 


$EXTENSI0NS 0N$ 




$INIT_ZEROES 0FF$ 


One-line description: 


ttdefine number_of pages 100 


> = does not work with float type 


int program page[T; 




delete_pagelpage_number) 


Problem: 


int page number; 


Comparison of real numbers using "less than or equal" (LEO.) libraries 


{ 


may fail. 


int i,j; 


Temporary solution: 


for (i-page number; i < (number of pages - 2); ++i) 


Break the comparison into two separate tests 


{ 




program_page[i] » program_page[i+l] ; (*This statement causes the 


Signed off 01/14/88 in release Z02.10 


} problem*) 


Number: 5000220186 Product: 8085 C 64826 01.04 






The code generated by the assignment statement is 


Keywords: CODE GENERATOR 






LXI D.Istatic (*???*) 


One-line description: 


DAD H 


When subtract an integer from a pointer, get unnecessary warning message 


DAD D 


- -0 


- -0 
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SHLD 


Ddelete page+0004H 


LHLD 


Ddelete page 


INX 


H 


LXI 


D.Istatic (*???* 


DAD 


H 


DAD 


D 


MOV 


E,M 


I MX 


H 


MOV 


D,M 


LHLD 


Ddelete page+0004H 


MOV 


E,M 


INX 


H 


MOV 


D,M 



Temporary solution: 

Use a temporary variable as the array index: 

de lete_page ( page_number ! 
int page number; 

r 
\ 

int i,j; 

for (i = page_number; i < (number_of_pages - 2); ++i) 



{ 



j + i + 1 ; 

program_page [i] = program_page [ j] ; 



Signed off 01/14/88 in release Z02.10 



Number: D200076919 Product: 8085 C 



54826 



01.04 



One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 
.■ ,-... 

"Z80" 

char array [ 12] ; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASM_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 1/14/88 in release 202.10 



SRB detail reports as of 01/14/88 
Number: D200077263 Product: 8085 C 
Keywords: CODE GENERATOR 



64826 
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One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

••C" 

"8088" 

mainl ) 

{ 



} 



double xx; 
xx = 2.0/3.0; 
xx = 2.0; 



xx is assigned the value 2.0 by both statements. 



This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx - 2.0/y; where y - 3.0; 

Signed off 01/14/88 in release Z02.10 



Number: D200079087 Product: 8085 C 
Keywords: CODE GENERATOR 



64826 



01.04 



One-line description: 

+ => -=, *-, & /= may fail to auto vars with $RECURSIVE 0N$ 

Problem: 

Composite assignment operators may fail to automatic variables when 

SRECURSIVE 0N$ is in effect. 

The following program segment illustrates this problem. 

"C" 

"8085" 

SRECURSIVE 0N$ 

functil, i2,doub) 
int il,i2; 
double doub; 
{ 

int answer; 



answer = 1; 
answer +■ i2*x; 



/* after this statement answer still is 1 */ 
/* however ii « i2 * x */ 



SRB detail reports as of 01/14/88 



Temporary solution: 

There is no known fix at this time. 

Signed off 01/14/88 in release Z02.10 
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Number: D200079160 Product: 8085 C 
Keywords: PASS 1 



64826 



01.04 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 

Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 

$SH0RT_ARITH 0FF$ 

short s; 

unsigned short us; 

ma int ) 

{ 



if ( (s/uspOxffff ) 

error ( ) : 
if ((usXs) 0x007f) 

error! ) 
if (us==s) 

error! ) 
if (s!=us) 

error! ) 
if (s<us) 

error! ) 
if (s>us) 

error! ) 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z02.10 



Number: D200080382 Product: 8085 C 64826 01.04 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 



To get the error: 



-0 



SRB detail reports as of 01/14/88 

"C" 

"68000" 

unsigned int a; 

main! ) 

{ 

a-0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 

Signed off 01/14/88 in release Z02.10 
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SRB detail reports as of 01/14/88 

Number: 5000152918 Product: 8085 EMULATION 



Page: 



64203 



49 
01.06 



One-line description: 

Can't use 9.5" paper to print mem map, due to centering of printout. 

Signed off 01/14/88 in release Z01.G7 



- -0 



50 
02.01 



SRB detail reports as of 01/14/88 Page: 

Number: 1650004598 Product: 8086/8 ASSEMB 64853 

One-line description: 

Wrong values during EQU from externals. 

Problem: 

The 8086 assembler assigns wrong values during equ from externals. 

Following program will show the bug : 

ext al,a2 (assigned somwhere else e.g. to 1 and 2) 
x equ a2 

here the value of al is assigned to x ! ! ! ! 

Temporary solution: 

No known workaround at this time. 

Signed off 01/14/88 in release Z02.70 



Number: 1650013235 Product: 8086/8 ASSEMB 



64853 



02.03 



One-line description: 

Tabs in source file are expanded to 6 spaces instead of 8 spaces 

Problem: 

The first tab encountered in the source code is expanded 
to 6 characters instead of the expected 8 blanks, causing 
unaligned fields in the assembly listing output. 

Temporary solution: 

Do not put tabs in the source code. 

Signed off 01/14/88 in release Z02.70 



Number: 5000136085 Product: 8086/8 ASSEMB 



64853 



02.00 



One-line description: 

Assembler/linker does not correctly handle EQU <EXT_LABEL> statement. 

Problem: 

Temporary solution: 

Don't use the statement 

F001 EQU OFFSET LABI 

Put the address calculation part of the expression in the MOV statement 
something like 

MOV AX, OFFSET LABI 

In other words the EQU statement is not correctly resolved by the 
assembler /linker. 

Signed off 01/14/88 in release Z02.70 



- -0 



SRB detail reports as of 01/14/88 

Number: 5000170415 Product: 8086/8 ASSEMB 



64853 
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02.03 



One-line description: 

The noload files aren't showing up in the listing; absolute correct 

Problem: 

Noload files are being linked correctly. They do not appear in the 
absolute file. However, the listing shows these files as loaded. 
The expected parenthesis around the no load file is not present. 

Temporary solution: 

No known temporary solution for the listing problem. Emulation 

can verify that the absolute is correct. 

Signed off 01/14/88 in release Z02.70 



Number: 5000 172593 Product: 8086/8 ASSEMB 
Keywords: LINKER 



64853 



02.03 



One-line description: 

Label preceeded with WORD PTR, NEAR PTR, etc. will not appear in the xref 

Problem: 

A label which is preceeded by a psuedo like NEAR PTR, WORD PTR, 

etc. does not appear in the assembler's xref in the references 

column. 

' processor name" 

1 LABI MOV AW,#0H 

2 BZ NEAR PTR LABI 

3 BR LABI 

4 END 



Cross Reference table: 



LINE# SYMBOL 
1 LABI 



TYPE 

P 



REFERENCES 
3 < should also have 2 



Temporary solution: 

Do xref on the 64100. Problem only occurs on host computers. 

Signed off 01/14/88 in release Z02.70 

Number: 5000201012 Product: 8086/8 ASSEMB 64853 

Keywords: CODE GENERATOR 

One-line description: 
Incorrect Object code generated 



02.02 



Problem: 



0000 2E8A84000C 



1 "8086" 

2 ASSUME CS:PR0G 

3 PROG 

4 MOV AL,FIX[SI] 

- -0 



SRB detail reports as of 01/14/88 
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0005 2E8A8C000C 
000A 2E8B84000C 
000F 0B1621 

ERR0RS= 



5 MOV 

6 MOV 
7FIX DB 



CL FIX [SI 1 

AX^WORD PTR FIXlSI] 

11,22,33 



IN ABOVE PROGRAM, ASSEMBLER DOES NOT COUNT ADDRESS CORRECTRY. 
000F SH0UD BE GENERATED. (NOW O0OC) 

The address 0C that is used for addressing FIX[SI] points to 
the middle of line 000A. The three addresses 0C should point 
to line 0000F. This is a bug in the most recent SMS. 

Signed off 01/14/88 in release Z02.70 



Number: D200060509 Product: 8086/8 ASSEMB 
Keywords: LINKER 



64853 



02.01 



One-line description: 

Linker generates error if C0MN segment is not 0000H 

Problem: 

This SR was originally entered under the operating system, SR#5000- 

143487. 

The linker generates a "Max addr or seg boundry exceed" when the COMN 
area is used and when its segment is not OOOOH. 

For Example: Linking a file that uses the COMN psuedo instruction 
at 010001000,010002000,010003000, will result in this error. 

Temporary solution: 

No known temporary solultion. 

Signed off 01/14/88 in release Z02.70 



Number: D200077768 Product: 8086/8 ASSEMB 

One-line description: 
reusing accumulator 

Problem: 

The AX register is being destroyed: 

"80186" 

{EXTENSIONS 0N$ 
$P0INTER_SIZE=32$ 
$SEPARATE_C0NST 0FF$ 
PROGRAM CL; 

TYPE 

U_8 * UNSIGNED_8; 
U_16 = UNSIGNED_16; 



64853 



02.01 



3RB detail reports as of 01/14/88 
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U_32 = UNSIGNED_32; 






Number: 5000226613 Product: 8086/8 ASSEMB 300 64853S004 02.20 


IDS = U_8(0)..U_8(9); 






Keywords: LINKER 


BASE CLK = RECORD 

HEAD : U 8; 

TAIL : U 8; 

SIZE : U 8; 
END; 

CLSREC = RECORD 
TOTCNT : U 32; 
Z PAD : ARRAYtU 16(0).. U 16(500)] OF U 8; 
ND; 

AR 






One-line description: 

Linker can generate invalid DATE on listing file. 

Problem: 

Very infrequently, the linker generates an invalid DATE on the listing 
file. When file are compiled or assembled on 9/01, the DATE file shows 
as 32 Aug 1987. 

FILE/PROG NAME PROGRAM DATA COMMON ABSOLUTE DATE TIME 


boot.R 00000400 TUE, 32 Aug 1987, 


CLSSR : ARRAY [U 8(0)..U 8(1), IDS] OF BASE BLK; 
CR : ARRAY[U_8(1)..U_8(48)] OF CLSREC; 






Temporary solution: 

There is no work around at this time. 


FUNCTION GCNT(ID:IDS):U 16; 
VAR 






Signed off 01/14/88 in release Z02.70 


CH : U 8; 

BEGIN 

$LIST CODE ON$ 

GCNT := CR[CLSSR[CH, ID]. HEAD] .TOTCNT; 




MOV AL,#+00003H 

MUL SS:BYTE PTR [BP+00004H] 

ADD BX.AX 

MOV AL,DS:BYTE PTR [BX] 

MOV AH,#0 

MUL AS AX GETS DESTROYED HERE 

ADD SI, AX 

MOV AX,DS:W0RD PTR [SI] 








SLIST CODE 0FF$ 
END; 








Temporary solution: 

There is no known work around at this time. 








Signed off 01/14/88 in release Z02.70 








- -0 


- -0 
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Number: D200079335 Product: 8086/8 ASSEMB 

Keywords: CODE GENERATOR 
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55 
02.50 



One-line description: 

VMS Hosted linker does not recognize logical names 

Problem: 

Detailed Listing for Defect Number LSDqf00689 



Submission Number: 00663LSDqf 
Defect Status: OPEN 
Prod/SCnS :/lsd/pplus/cmd/lnk 
Version : current 
Severity. 1 
Showstopper: No 
Workaround: No 
Defect /Enhancement: 
* defect 



Date Found: 870817 

Date Arrived: 870817 

Date Received: 870820 
Date Resolved: 

Number of Duplicates: 
Additional Files: 1 



(estimated) 



Text: 

VMS hosted linker does not recognize logical names 



Submitter Supplied Information 

Submitter name: Lee Jackson 

Submitter phone: 

Submitter address: lee 

Activity used to find defect: casual use 

Responder Supplied Information 

Responsible site: LSD 
Responsible project: stars 
Responsible engineer: STARS II 



.submitter 

When the linker is given a file name it does not test to see that the 
name is a logical name, thus if the name is a logical name, the linker 
will not open the appropriate file. 

Temporary solution: 

There is no known work around at this time. 



Signed off 01/14/88 in release 202.70 



SRB detail reports as of 01/14/88 
Number: 1650026708 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 
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03.01 



One-line description: 

Right shift using var. for # of places to shift generates bad code 

Problem: 

The following program generates incorrect code: 

"C" 
"8086" 

ma in ( ) { 
int a ; 

unsigned b; 
a - 5 > > b; 

/* negates and then does a left shift instead of a right shift */ 
a » 5 >> 3; 

/* works fine */ 
a = 5 < < 3; a = 5 < < b; 

/* both work fine */ 
} 

Temporary solution: 

Manually edit the ASM8086 file, generated using $ASM_FILE$, and 

assemble. 

Signed off 01/14/88 in release Z03.70 



Number: 2700005520 Product: 8086/8 C 
Keywords: RUN-TIME LIBRARY 



64818 



00.00 



One-line description: 

REAL NUMBER COMPARISONS MAY NOT EVALUATE CORRECTLY. 

Problem: 

There is a problem with REAL COMP in the 8086 C real number library 

when mantissas are compared. Real numbers declared as float or double 
do not compare correctly when they differ in the sixth figure. 



double a, b; 
a = 12.3456; 
b ' 12.3455; 

if (a > b) 
result = 1; 

else if (a == b) 
result = 0; 

else result = 2; 



/* can also be declared float */ 



/* result = after this code is executed */ 



Temporary solution: 

No known temporary solution at this time. 



- -0 



SRB detail reports as of 01/14/88 
signed off 01/14/88 in release Z03.70 
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Number: 5000134593 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



02.01 



One-line description: 

1102 error generated - register needed but not availiable 

Problem: 

The following program generates a 1102 -register needed but not 

available error: 

"C" 

••8086" 

struct test { 
int bbb; 
short aaa: 
}; 

bbb(ptr) 

struct test *ptr; 
{ 

short x; 
x = ptr -> aaa >> 4; 

main! ) 
{> 

The assembly code mneumonics generated for the expression, 
x = ptr -> aaa >> 4, included: 

mov cl, #+00004H 

push ex 

mov ch, (some variable) 

pop ex 

shr ch, cl (ch is unknown after the pop) 

This same code was genrated by the Pascal compiler, SR#5000-138388. 

Signed off 01/14/88 in release Z03.70 

Number: 5000134601 Product: 8086/8 C 64818 02.01 

Keywords: CODE GENERATOR 

One-line description: 

Incorrect segment of array transfered to pointer 

Problem: 

ES is used to store the segment of an array but DS is loaded into the 

pointer+2H. 

"C" 

"8086" 

$FAR_EXTVARS$ 

$POINTER_SIZE 32$ 

extern struct {int a,b[3],c;} ary[5]; 

- -0 
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int *p, i; 

foolO 

{ p=&ary[i].b[i];} 

MOV AX.SEG ary 

MOV ES.AX {segment of ary in ES} 

MOV DS:W0RD PTR Dstatic+2H,DS {moves incorrect segment into ptr} 

mainOO 

Temporary solution: 

The following program generates the correct code: 

extern struct Tint a,b[3],c;} *p,ary[5]; 

int *t,i; 

f() { p=&ary[i]; 

t-M*p).b[i];} 

Signed off 01/14/88 in release Z03.70 



Number: 5000136267 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



02.01 



One-line description: 

ES register corrupt when used to get address of array to place in ptr. 

Problem: 

The following program places the incorrect segment of an array 

address into a pointer. 
„ c „ 

••8086" 

$P0INTER_SIZE 32$ 
$FAR_EXTVARS$ 

extern int var [10] [10] ; 
extern int *point; 

mainO { int x,y; 

point = &var[x] [y] ; 
MOV AX,#+0014H 

MOV AX.SEG var 

MOV ES.AX {ES contains the segment value of var} 

MOV AX.SEG point 

MOV ES.AX {ES contains the segment value of point} 

MOV ES:W0RD PTR point+00002H,DS {DS is unknown} 
} 

The segment value for var should have been loaded into DS, or PUSH on th 
e stack. 

Temporary solution: 
Temporary solution: 

extern int var [10*10]; 
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extern int *point; 

main ( ) { int x,y; 
int p; 
p= x*10+y; 
point - &var[p] ; 

} 

Signed off 01/14/88 in release Z03.70 

Number: 5000149229 Product: 8086/8 C 64818 03.00 

Keywords: CODE GENERATOR 

One-line description: 

Return statement not putting value on BX register 

Problem: 

In the following program, the code generated for case 4 

does not return a value in the "BX" register. A "12" is 

put in the accumulator, but nothing ever happens to it. 

When the program is getting ready to return we need the 

following command: 

MOV BX,SS:W0RD PTR {BP_00008H] 

/*******Sample program***********/ 

"C" "8086" 

$SEPARATE_CONST OFF$ $P0INTER_SIZE=32$ $FAR_EXTVARS$ 

$FULL_LIST OFF$ $AMNESIA 0N$ $EXTENSIONS 0N$ $INIT_ZEROES 0FF$ 

$FAR_PR0C 0N$ $FAR_LIBRALIES 0N$ 

struct 

{ 

int ino; 
} index [160]; 
splOmainl) 
{ 

int l,c; 
while(l) { 

switch (c) { 

case 4: return! 12) ; 

case 1: for (1=15; index [ (2*l+c)*16+l] . ino<0; 1--) ; 
} 
} 



Temporary solution: 

Breaking up the expression for the array value of index [] 
causes the compiler to generate the correct code. Create 
an "int" type variable: 

int k 
k=(2*l+c)*16+l 

and use this inside the 'for' loop 



- -0 



SRB detail reports as of 01/14/88 
Signed off 01/14/88 in release Z03.70 
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Number: 5000149757 Product: 8086/8 C 



64818 



03.02 



One-line description: 

Code generated for illegal C statement - POP BH generated 

Problem: 

The C compiler generates invalid code for the following program. 

"C" 

"80188" 

$FAR_EXTVARS, POINTER_SIZE 32$ 

struct Button_def { 

char *(*labels) [] ; 
}; 

extern struct Button_def Button_List[] ; 

Draw_Button (but ) 
char but; 

{ 

struct Button_Def *but_p; 
char *lab_p[] ; 
char b index; 

but_p = &Button_List[bindex] ; 
lab_p » *but_p->labels; 

/*generates invalid code including a POP BH*/ 
} 

The compiler does not flag an error when a pointer is being assigned 
to a constant address with no memory associated with it. For example, 
lab_p is the name of an array. There is memory allocated for each of 
the array elements (i.e. lab_p[2]), but the name lap_b has no memory 
associated with it. THerefore, you should not be able to write "lab_p 
« whatever". Our compiler, however, attempts to generate code for this 
statement. ( Note that the s/w going out in the October suds generates 
a "60:Lvalue expected" error for this statement). 

Temporary solution: 

One possible way to get the desired results is: 

"C" 

"80188" 

$FAR_EXTVARS, POINTER_SIZE 32$ 

struct Button_Def 

{ char *(*labels) []; 
>; 

extern struct Button_def Button_List [] ; 

Draw_Button(but) 
char but; 

{ struct Button_Def *but_p; 
char **lab_p; 

- -0 
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char b index; 

but_p = &Button_List [b index ] ; 
lab p = *but p->labels; 
} 

labels is a ptr to an array of ptrs. to chars. 
lab_p is now a ptr to a ptr to chars. 

These two can now be equated. 

Signed off 01/14/88 in release Z03.70 

Number: 5000149765 Product: 8086/8 C 64818 03.02 

One-line description: 

Address of array element incorrectly calculated 

Problem: 

The following program causes the processor to go into the weeds. 

"C" 
"80188" 

$FAR_EXTVARS, POINTER_SIZE 32$ 
struct ButtonjDbj { 

char butxl, butyl, butx2, buty2; 

char button_code, label_code; 

char button^parm, button_attrib; }; 
#define diasable_bTt 0x08 
extern int Button; 

extern struct Button_0bj Current_Buttons[] ; 
extern char obj_index; 

State_Machine( ) { 
char B_code; 
int Error; 

if ( Button != OxFFFF) 
{ 
SMI: obj_index = ( Button & OxFF ); 
Button = OxFFFF; 

if ((Current Buttons[obj index] .button attrib & disable bit) = 
- 0) _ 

{ } 
} 
} 

The code generated for the last if statement looks like: 
MOV AX.SEG obj_index 
MOV ES,AX 

MOV BL,ES:BYTE PTR obj_index 
MOV BH, #0 
SHL BX,#+00003H 
MOV AX,SEG Current_Buttons 
MOV ES.AX 

MOV AL, ES:BYTE PTR Current_Buttons[BX+07H] 
etc. 
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WHen tracing the emulation the same statement as MOV AL,ES:BYTE PTR 
Current_Buttons[BX+07H] becomes BX+08H. 
This may be incorrect. 

The program was loaded at 1000h,2000h, 3000h. The monitor was loaded at 
4000H,5000H,6000h. 

The second file consists of : 

■•C" 

"80188" 

"$FAR_EXTVARS, P0INTER_SIZE 32$ 

struct Button_0bj { 



Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release Z03.70 



Number: 5000162487 Product: 8086/8 C 64818 " 03.02 

Keywords: CODE GENERATOR 

One-line description: 

Vax not creating same code as the 64000 

Problem: 

8086 C compiler rev 3.4 on Vax does not create the same code as the comp 
iler on the 64000. The code on the 64000 is correct. The code on the 
VAX is not. 



"C" 

"8086" 

#$LIST_C0DE$ 

#$LIST 0N$ 

testO; 

double temp; 
temp=0.5; 
temp=l. 0/2.0; 
} 



64000 creates the following VAX creates these: 
for both assignment statements: 



LEA SI,DS:CONST_data 
LEA DI, , 



DATA 

CONSTjJata 

DB 000H,000H,000H,00OH 
000H,000H.0E0H,03FH 



<■= that for the temp=0.5 

this for the 1.0/2.0 
LEA SI,DS:C0NST data+0008H 



DB OOOH,OOOH,0O0H,OOOH 
OOOH,0OOH,OE0H,O3FH 



Temporary solution: 

There is no known work around at this time. 

Signed off 01/14/88 in release Z03.70 



- -0 
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Number: 5000163410 Product: 8086/8 C 
Keywords: PASS 1 



6481S 



03.02 



One-line description: 

compiler using DS segment rather than ES segment for 32 bit pointers 

Problem: 

When 32 bit pointers are used with structures the DS segment is moved 

rather than the ES segment. This occurs if arithmatic is done in a 

parentehsis. 

EXANPLE: 

"C" 

••80186" 

$P0IK1ER_SIZE 32$ 
$FAR_EXTVARS 0N$ 

struct cmd_exe_struct{ 
int test; 

int opt parms[16] ; 
}; 

extern struct cmd_exe_struct cmd_exe[]; 

ma int ) 

{ 

int dev,*ptr; 

ptr = cmd exe[dev-l] .opt parms; 

} 

Temporary solution: 

Assign arithmatic operations within parenthesis to a temporary 

variable. 

Signed off 01/14/88 in release Z03.70 

Number: 5000165134 Product: 8086/8 C 64818 03.02 

Keywords: CODE GENERATOR 

One-line description: 

BX register overwritten with a switch statement 

Problem: 

The following program causes the BX register to be overwritten while 

calculating the index of the array. 

"C" 

"80188" 

SEXTENSIONS 0N$ 
$FAR_EXTVARS$ 
^POINTER SIZE=32$ 
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extern char Channel_Data[6] [9] , SelectedTrace, SIchnl_type; 
tdefine ECG 
#define SI_ECG_btns 
char btns; 

SIchannel_sel (chnl_type, chnl- index ) 

char chnl type, chnl index; 
{ 
switch (Channel_Data[SelectedTrace] [SIchnl_type] ) 

MOV AL,#+00009H 

MOV CS.SEG SelectedTrace 

MOV ES.CX 

MUL ES:BYTE PTR SelectedTrace 

MOV BX,AX 

LEA BX,DS:Channel_Data[BX] puts address of Channel_Data in BX 



MOV BL,ES:BYTE PTR SIchnlJType reuses BX 
MOV BH,#0 lost!!! 

ADD BX.BX 



case(ECG) : 

btns = SI_ECG_btns; 
break; 



Temporary solution: 

There is no known work around at this time. 

Signed off 01/14/88 in release Z03.70 



Channel Data address 



Number: 5000172239 Product: 8086/8 C 



64818 



03.02 



One-line description: 

external used 2x in same pgm, w/ ASM_FILE ON, get 2 EXT stmts in ASMfile 

Problem: 

The following C program, when, using ASM_FILE ON, puts 2 EXTERNAL 

zzz statements, and then the ASM70108 file will not assemble. 

"C" 

"8086" 
$ASM_FILE 0N$ 

b() 

{ 

extern zzz; 

} 

c() 

- -0 
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{ 

extern zzz; 

} 

The ASM70108 file looks like this: 

"70108" 

; 1 0000 "C" 

EXTERNAL zzz 

EXTERNAL zzz 
' ERROR-ET 

ET - Expression Type 

07/24/87 LSD STARS DTS LINK 

07/24/87 LSD STARS DTS LINK 

07/24/87 LSD STARS DTS LINK 

Temporary solution: 

No known solution at this time. 



Signed off 01/14/88 in release Z03.70 
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COPIED TO D200078766 
COPIED TO D200078774 
COPIED TO D200078782 



64818 

64818S001 

64818S004 



Number: 5000186718 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.01 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main! ) 
{ 

double xx ; 

xx = 2.0/3.0; 

xx = 2.0; 
} 
xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 



Temporary solution: 

xx = 2.0/y; where y 



3.0: 



Signed off 01/14/88 in release 203.70 



Numb er: 5000193466 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.01 



One-line description: 

When using calculated value for array index, uses BX register twice 
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Problem: 

When compiling the next source, compiler generates incorrect codes. 
"C" 

"8086" 

$FAR_EXTVARS$ $P0INTER_SIZE=32$ 
$FAR_LIBRARIES+$ $SEPARATE_CONST+$ 
extern long CP0S[4] ,PCMDTBL[6] [50] [8] ; 
maint ) { int stepno; 

stepno=l; 

PCMDTBL[0] [stepno-1] [1]-CP0S[1]; } 

The assembler listing file is as follows. 

LES BX,SS:DWORD PTR[BP-00006H] (1) 

MOV BX.SEG PCMDTBL (2) 

MOV ES,BX (3) 

POP ES: [BX+00004H] 

POP ES: [BX+00006H] 
} END OF 1/2 

Compiler sets the offset address of PCMDTBL[0] [stepno-1] [1] to BX 
register (line(D). 

But BX register is set the segment address of PCMDTBL at line (2). 
Temporary solution is as follows. 

int stepno, X; 

stepno=l; 

X=stepno-l; 

PCMDTBL[0] [X] [1]=CP0S[1] ; 



66 



8086 C generates incorrect codes. 
Array's address isn't correct. 



END OF 2/2 



Please refer to the verifier text No. 1/2. 



- -0 



END OF 1/2 
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END OF 2/2 



Temporary solution: 

No know solution at this time. 

Signed off 01/14/88 in release Z03.70 



Number: 5000195628 Product: 8086/8 C 



64818 



03.01 



One-line description: 

ES reg overwritten when assign char array to complex data structure 

Problem: 

8086 C produces wrong code for assigning a character array to a complex 

data structure. Example Prog: 

"C" 

"8086" 

^OPTIMIZE 0FF$ 

$FIXED_PARAMETERS ON, EXTENSIONS ON,FAR_LIBRARIES ON$ 

$FAR_PR0C 0N,P0INTER_SIZE 32, SEPARATE_C0NST OFF, RECURSIVE 0N$ 

$FAR_EXTVARS ON$ 

struct fibtab { 

char name [20] ; 

char typ; 

char att; 

int first; 

int max; 

int last; 

int byte, date, use, reserve; }; 

char directory [64] ; 

struct dir { 

int maxanz; 

struct fibtab f ib[l] ; 

int link; 

); 

ma int ) 
{ 

int i.wert; 

char *stringl,*string2,zeil[10] ; 

struct dir *zei2; 

- -0 
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zei2 = (struct dir *) directory; 

for (i=0;i<10; i++) 
zeilti] = '\0' ; 

for (i=0;i<4; i++) 
zeil[i] = 'A' ; 

stringl = zeil ; 

string2 = zei2 ; 
wert = 0; 
i = 0; 

while ( (zei2->f ib[wert] .name[i] - zeilti] ) != '\0' ) 
i++ ; /* this works fine ! */ 



while ( (zei2->f ib[wert] .name[i] = stringlti] ) != '\0' ) 

i++ ; /* this should do alike, its just using */ 
/* a pointer instead of an array name */ 
/* however with the 8086 C compiler it */ 
/* produces bad code. The ES register is */ 
/* used to addres zeis-> fib[wert], then to */ 
/* address stringl [], then it is assumed */ 
/* that ES register is still loaded w/ */ 
/* fib[wert] addresses for adding .name[i]V 



Temporary solution: 

Use an array name instead of a pointer. 

Signed off 01/14/88 in release Z03.70 

Number: 5000201749 Product: 8086/8 C 64818 03.20 

Keywords: CODE GENERATOR 

One-line description: 
compiler reusing CX register 

Problem: 

This program causes the CX register to be used twice, without being 

reintialized in between uses. 

"C" 

"8086" 

struct struct3 {char elel; char ele2; char ele3;}; 

struct structs {char elel; char ele2; char ele3; char ele4; char ele5; 
char ele6; char ele7; char ele8;}; 

funcO 
{ 

char c; 

int i; 

- -0 
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struct struct8 (*src)[100]; 
struct struct3 (*dest)[4]; 

c=(*src) [i] .ele3; 

(*dest) [i].ele2=c; 
} 

reinitialized inbetween uses. 

Temporary solution: 
Create ASM file and modify 

Signed off 01/14/88 in release Z03.70 

Number: 5000203596 Product: 8086/8 C 64818 03.30 

Keywords: CODE GENERATOR 

One-line description: 

Problem w/ unreleased Rev. Dx Register destroyed 

Problem: 

DX register using temporary data buffer was destroyed by calculateing 

the address of external variable, before using this temporary data. 



SRB detail reports as of 01/14/88 

Signed off 01/14/88 in release Z03.70 
Number: 5000216036 Product: 8086/8 C 
Keywords: LINKER 
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03. 10 



One-line description: 

The noload files aren't showing up in the listing, absolute correct 

Problem: 

Noload files are being linked correctly. They do not appear in the 
absolute file. However, the listing shows these files as loaded. 
The expected parenthesis around the no load file is not present. 
This problem is also found on the Series 300 

Temporary solution: 

There is no known solution at this time. 

Signed off 01/14/88 in release Z03.70 



Number: 5000223800 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.02 



One-line description: 

Bad code generated for address of external character if for loop 



example: 








Problem: 


funcl lncin, lncout) 








The following program generated code that did not reference the 


unsigned short lncin; 








external variable correctly: 


unsigned short lncout; 










struct tgcntb { 








"C" 


{ char *cinpa, 








"8086" 


*couta; 








$FAR PR0C 0N$ $FAR LIBRARIES 0N$ $P0INTER SIZE =32$ 


unsigned int cinpb 








$SEPARATE CONST 0FF$ $INIT ZEROES 0FF$ $~FAR EXTVARS 0N$ 


coutb; 








extern char ** DISPJ2; 


} 








extern char ** DISPJ2end; 


extern struct centb[8] ; 








char *dme ; 


extern unsigned int centp,centc; 






int table_set (japan) 










int japan; 


if (centc < 8) 








{ 


$0PTIMIZE OFF$ 








char **cpl,**cp2; 


{ 








if (japan) { 


^OPTIMIZE ON$ 








for(cpl=&dme,cp2=&DISPJ2; cp2 < &DISPJ2end ;) 


centb[centp] . cinpb= lncin; 








*cpl++ =*cp2++; 


centbtcentp] . coutb=lncout ; 








} 


MOV DX,SS:W0RD PTR 


[BP+ 


00012H1 


} 


MOV AX,#+0OOOCH 










MOV DX.SEG centp 


) 


DX 


IS DESTROY 


The comiler should have pushed ES, instead of DS. 

Temporary solution: 

Use a temporary varible buf, to hold &DISPJ2end: 


Temporary solution: 










There is no know work around at 


this 


time. 


char **cpl,**cp2; 




— 


-0 




- -0 
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char ***buf; buf =&DISPJ2end; 
if (japan) { 

for (cpl=&dme,cp2=&DISPJ2;cp2 < buf) 

Signed off 01/14/88 in release Z03.70 
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Number: 5000229476 Product: 8086/8 C 
Keywords: SF1001 



64818 



03.02 



One-line description: 

When casting unsigned ints to floats using +=, generates a error #1001 

Problem: 

Program generates error #1001 when using summation "+=" and casting 

the result of a multiplication of 2 unsigned integers into a double. 

"8086" 

"C" 

unsigned int b[2][5] = { {l, l, l, l, 1},{1, 1, 1, 1, 1} }; 

unsigned int a[5] = {1, 1, 1, 1, 1}; 

double x; 

int CNTR; 

int XPIX; 

main! ) 

{ 

for (CNTR=0;CNTR=4;++CNTR) 

x += b[CNTR] [XPIX] * a[CNTR]; 

} 
THIS GENERATES AN ERROR #1001 

Temporary solution: 

Use: 

x - x + b[CNTR] [XPIX] * a[CNTR] 

or cast the right side of the equation into a float 

Signed off 01/14/88 in release Z03.70 

Number: D200025858 Product: 8086/8 C 64818 01.06 

Keywords: CODE GENERATOR 

One-line description: 

Argument to switch statement may be doubled. 

Problem: 

Switching on a dereferenced pointer to a structure field or on a multi- 
dimensional array field generates incorrect code which doubles the 
switch argument. The following is an example of this: 

"C" 

"PROCESSOR NAME" 

unsigned short i; 

struct { short z; short y[]; } *x; 

main!) { 
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} 



i = i; 

switchtx -> y[i]) { /*Generates code which doubles the argument*/ 
case 0: break; 
} 



Temporary solution: 

Set up a temporary variable of the appropriate type and assign the 

expression to it. Use the temporary in the switch statement: 

int temp; 
temp = x -> y [i] ; 
switch! temp) { 
. . . } 

Signed off 01/14/88 in release Z03.70 



Number: D200031476 Product: 8086/8 C 



64818 



02.00 



One-line description: 

Using a postfix decrement operator in a conditional statement fails. 

Problem: 

Using a postfix decrement operator in a conditional statement generates 
an incorrect comparison. When a value is supposed to be compared to 
zero, it is instead compared to -1. If the value is declared unsigned 
then this will never be true. The following code is an example: 

"C" 

"processor name" 
unsigned short i,j; 
char s[20] ,d[20]; 
ma int) { 

J - 10; 

for (i = 0; j — ; s[i++] = d[j]); /*compares j to -1, which it will 
} never be*/ 

The order of evaluation of the decrement operator is also incorrect, 
which is documented in SR #D200-031294. 

Temporary solution: 

Rearrange the expression so that the postfix decrement operator is not 

used: 

for (i = 0; j; s[i++] = d[— j]); 

Signed off 01/14/88 in release Z03.70 

Number: D200042606 Product: 8086/8 C 64818 02.00 

One-line description: 

Compiler uses wrong segment register. 

Problem: 

In the following example, the compiler forgets which segment register 

to use after several expressions involving pointers. 



SRB detail reports as of 01/14/88 



Page: 



73 



"C" 

"processor name" 

$P0INTER_SIZE=32$ 

test( ) 

{ 

int *p,*q,i,j; 

j=*(p+l); 

i=*p; 

q=p+2; /*listing looks like this: 

ADD BX,#+04H 

MOV SS:W0RD PTR [BP-00008H] ,BX 

MOV SS:WORD PTR [BP-00006H] ,DS 

"should be ES */ 
} 

Temporary solution: 

Turn $AMNESIA ON$ around that expression. 

Signed off 01/14/88 in release Z03.70 



Number: D200C49916 Product: 8086/8 C 



64818 



03.00 



One-line description: 

DX register is used although it is overwritten by IMUL instruction 

Problem: 

The value of the DX register is incorrect because it has been 

destructed by the IMUL instruction. 

Example: 

struct { 

char dummy 1; 
int varl; 
} block [12]; 
ROUTINE ( paraml , param2 ) 
int paraml; 
long param2; 
{ 
block [paraml] .varl = param2 /OxlOOOO; 



IMUL SS:W0RD PTR [BP+00008H] 

MOV SI, AX 

mov ES:W0RD PTR [SI-00FFFH] ,DX 



DX has been overwritten 
by IMUL 



return; 



Temporary solution: 

No known temporaray solution. 

Signed off 01/14/88 in release Z03.70 



- -0 
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Number: D200057802 Product: 8086/8 C 
Keywords: CODE GENERATOR 
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One-line description: 

Nonsense code generated by dynamic struc declaration in a funct. 

Problem: 

Dynamic data structures which access an array element of an unknown 

sized array cause the compiler to generate bad code. 

Temporary solution: 

No known solution at this time. 

Signed off 01/14/88 in release Z03.70 



Number: D200068684 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.01 



One-line description: 

Compile incorrect when a ptr to an int is casted as a short and incremen 

Problem: 

The following table describes the compiled files and their results 

on 64100. 









Number of 


increment 




test 


'if" 


Ptr 


increments; 


and 


gets 


BUG DESCRIPTION 


case 


used 


size 


statemnt 


separate 










separation 


statements 


TEST1 


yes 


32 


2 ; 


no 




Reboots system 


TEST2 


no 


32 


2 ; 


no 




No increments in listing 


TEST3 


yes 


32 


2 , 


no 




No increments in listing 


TEST4 


yes 


16 


2 ; 


no 




Reboots system 


TEST5 


no 


16 


2 ; 


no 




compiles correctly 


TEST6 


yes 


16 


2 , 


no 




Reboots system 


TEST7 


yes 


32 




no 




No increments in listing 


TEST8 


yes 


16 




no 




Reboots system 


TEST9 


no 


32 




yes 




error in factor message 


TEST10 


no 


16 




yes 




error in factor message 


TEST 11 


no 


32 




yes 




No increments in listing 


TEST12 


no 


16 




yes 




No increments in listing 



Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release Z03.70 

Number: D200070532 Product: 8086/8 C 



64818 



03.02 



Keywords: CODE GENERATOR 

One-line description: 

Incorrect segment passed to external function 



- -0 
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Problem: 






The compiler passes the incorrect segment to an external function. 


The compiler passes the incorrect 


segment to an external 


function. 


"C" 
"8088" 


"C" 






"8088" 






#define ushort unsigned short 


#define ushort unsigned short 






♦define uint unsigned 


#define uint unsigned 






SPOINTER SIZE 32$ 


SPOINTER SIZE 32$ 






$FAR EXTVARS$ 


SFAR EXTVARS$ 






$INIT ZEROES 0FF$ 


SINIT ZEROES 0FF$ 






SSEPARATE CONST 0FF$ 


SSEPARATE CONST 0FF$ 






$FAR LIBRARIES 0N$ 


$FAR LIBRARIES 0N$ 






$FAR PROC 0N$ 


$FAR PROC ON$ 






SENTRY OFF$ 


SENTRY 0FF$ 






extern char m[2] [4] [8] ; 


extern char m[2][4][8]; 






extern ushort a[5); 


extern ushort a[5]; 






extern movb( ) ; 


extern movbt ) ; 






char *p; 


char *p; 






proc(ptr.num) 



proclptr.num) 
char *ptr; 
uint num; 
{ uint r,j,k; 



movb( m[k] [r] ) ; 

/* MOV CL,#+00005H 

MOV BX,SS:W0RD PTR [BP-00002H] 

SHL BX.CL 

LEA BX,DS:m[BX] 

MOV AX.SEG m 

MOV ES,AX 



offset loaded into bx 
segment for m into ES 



PUSH DS 

PUSH BX 

CALL FAR PTR movb 

: */ 



DS passed to movb() not ES 

WRONG 



This problem occurs on version 3.20 of the compiler. ES should have 
been pushed on the stack instead of DS. 

Signed off 01/14/88 in release Z03.70 



Number: D200070615 Product: 8086/8 C 

Keywords: CODE GENERATOR 

One-line description: 

Incorrect segment passed to external function 



64818 



03.01 



Problem: 



- -0 



char *ptr; 

uint num; 

{ uint r,j,k; 

movbt m[k] [r] ) ; 

/* MOV CL,#+00005H 

MOV BX,SS:W0RD PTR [BP-00002H] 

SHL BX.CL 

LEA BX,DS:m[BX] 

MOV AX,SEG m 

MOV ES.AX 



offset loaded into bx 
segment for m into ES 



PUSH DS 

PUSH BX 

CALL FAR PTR movb 

: */ 



DS passed to movb() not ES 

WRONG 



This problem occurs on version 3.20 of the compiler. ES should have 
been pushed on the stack instead of DS. 

Signed off 01/14/88 in release Z03.70 



Number: D200072371 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.01 



One-line description: 

Assignment to ptr var. (w/ Separate_const off) causes corrupt stack 

Problem: 

The following program generates an incorrect number of PUSH'S 

- -0 
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and POP's. The problem did not occur on rev. 3.01. 

"C" 

"8086" 

$POINTER_SIZE 16$ /* pointer_size 32 has this problem also */ 
$SEPARATE_CONST 0FF$ /* required for problem to occur */ 

main () 

{ double *a; 
*a++ = 0.0; 

/* MOV AX,SS:W0RD PTR [BP-00002H] 

ADD SS:W0RD PTR [BP-00002H] ,#+00008H 

LEA Sl,DS:Const_prog 

PUSH DS - saves the value of ds 

missing a PUSH CS here to set up for the MOVSB 

MOV BX,AX 

LEA DI.DS: [BX] 

MOV CX,#+00008H 

PUSH DS 

POP ES 

CLD 

POP DS 

REP MOVSB 

POP DS 

Nothing 



• cs should have been loaded into ds but wasn;t 
left on the stack from this routine 



} 



V 



This problem also occurs without the increment. Any constant assignment 
to a dereferenced pointer that generates a MOVSB instruction will cause 
the problem (i.e. pointers to long, double, strings) . This problem is 
caused only when the constants are being stored in the code segment 
(C0NST_prog). 

Temporary solution: 

Modify the assembly file, generated with the $ASM_FILE 0N$ 

directive, to include the required PUSH CS and assemble. 

Signed off 01/14/88 in release Z03.70 



Number: D200074237 Product: 8086/8 C 



64818 



03.02 



One-line description: 

PROGRAMS WITH DUPLICATE GOTO LABELS MAY FAIL IN PASS 3 

Problem: 

C programs with duplicate user labels) for goto'slmay fail in pass3. 

The current SUDS C compilers may produce the error 
"comp: failed; too many errors in pass 3." 
from some C programs which previously compiled correctly. 

This problem did not appear in any C compilers before April 1987. 

In C it is valid to use the same goto label symbol in different 

- -0 
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However, the HP64000 C cross will inform the user that these symbols 
are duplicate in the pass3 on the compiler. These symbols would 
produce duplicate label definitions when defined the ASM_FILE output 
is assembled. In addition the emulation products will only find one 
of these symbols. 

The duplicate symbol detection algorithm on the HPUX/300, HPUX/500 
and VAX/VMS C language compilers has an error which causes the 
compiler to fail. 

However, the duplicate symbol checking is done after all of the 
relocatable and asmb_sym files have been produced. These output 
files are equivalent to those produced in the HP64000 version compilers. 
Thus, the output of the compilers is still correct, except for some 
trailing lines in the listing file. 

The following program will cause this defect to occur: 

••C" 

"6800" 

/A-***********************************************************/ 

/* TEST file for problem with duplicate local labels */ 



/* 



V 



/* This program fails in pass 3 on VAX & HPUX/500 &/300 */ 
/* While checking for duplicate asmb_sym symbols */ 
/* due to the "duplicate" error_exit labels */ 



/* 



V 



/* The workaround */ 

/* is to use the same local symbol only once per module */ 
/ ^ 



**************************#***»***************************** . 



int i; 
testli ) 
{ 

/* ... V 
if (i == 77) goto error_exit; 

/* ... */ 
error_exit: 

i = -1; 
/* ... */ 
} 
/* duplicate symbol should be created */ 

test2() 
{ 

/* ... */ 
if (i == 137) goto error exit; 

/* ... */ 
error exit: 



-1; 
V 
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Signed off 01/14/88 in release Z03.70 
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Number: D200077396 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.02 



One-line description: 

VAX and 64100 generate different constants. VAX is incorrect. 

Problem: 

There is a problem with the double constant divide: 

"C" 

"8088" 

main! ) 

{ 

double x; 

x=3. 1415926535898/ 180.0; 

} 

The program generates an incorrect constant on the VAX, the 64K 
code is fine. 

Temporary solution: 

There is no known solution at this time. 

Signed off 01/14/88 in release Z03.70 



Number: D20O077727 Product: 8086/8 C 64818 

Keywords: CODE GENERATOR 

One-line description: 

CL register being used twice 

Problem: 

Compiler uses CX register for two different values 

example: 

"C 
"8088" 

#define ushort unsigned short 
#define uint unsigned 

$FIXED_PARAMETERS ON$ 
$P0INTER_SIZE=32$ 
$SEPARATE_CONST 0FF$ 
SFAR_LIBRARIES 0N$ 
$FAR_PR0C 0N$ 
$FAR_EXTVARS$ 

uint arrl[3][2],arr2[40]; 
ushort i; 

main( ) 

- -0 
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{ 

$LIST_C0DE 0N$ 

arr2[20] = arrlfi] [0]/100+30; 

MOV CX,#+00064H <— -load CL w/ 100 decimal 

MOV BL,DS:BYTE PTR Dstatic+0005CH 

MOV BH,#0 

MOV CL,#+00002H < CL loaded w/ 2H before 

SHL BX.CL it can be used for divide 

MOV AX,DS:W0RD PTR Dstatic[BX] 

SUB DX,DX 

DIV CX < — dividing by 2 not 64H 

ADD AX,#+0001EH 

MOV DS:W0RD PTR Dstatic+00034H, AX 
$LIST_C0DE 0FF$ 

Temporary solution: 

There is no know work around at this time. 

Signed off 01/14/88 in release Z03.7Q 



Number: D200079111 Product: 8086/8 C 
Keywords: PASS 1 



64818 



03.02 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 

Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SHORT_ARITH 0FF$ 

short s; 

unsigned short us; 



ma int ) 

{ 



} 



if ( (s/uspOxffff ) 

errort ) : 
if t(us%s) 0x007f) 

errort ) ; 
if (us==s) 

errort 
if (s!=us) 

errort ) ; 
if (s<us) 

errort '. 
if (s>us) 

errort ) : 



/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z03.70 
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03.02 



One-line description: 

Cannot prevent adding Esymbol and Rsymbol info to global symbol table 

Problem: 

When using the linker on the VAX one does not have the capability to 
prevent adding Esymbol and Rsymbol information to the global symbol 
table. This presents a problem for me because I currently have 
approximately 10,000 global symbols in my source code and when I link 
the files this grows to approximately 30,000 symbols because the E and 
R values are added to the linklisting. It becomes very difficult to 
deal with this much information especially since the E and R values are 
of no use to me. I need the capability to turn off the calculation of 
the Entry and Return values for global symbols. 

Temporary solution: 

There is no known solution at this time. 

Signed off 01/14/88 in release Z03.70 

Number: D200080333 Product: 8086/8 C 64818 03.02 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 

"C 

"68000" 

unsigned int a; 

main! ) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 

Signed off 01/14/88 in release Z03.70 
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Number: 1650038430 Product: 8086/8 C 
Keywords: CODE GENERATOR 
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One-line description: 

printer arithmetic gives warning "integer not pointer size" 

Problem: 

Incorrect warning message on instructions using pointers: 

char *p; 

*(p-2)=5; 

gives the message: 

515: Warning: integer not pointer size 

Temporary solution: 

Add, rather than subract from the pointer: 

*(p+(-2)) = 5; 

Signed off 01/14/88 in release Z03.70 
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Number: 5000221788 Product: 8086/8 C 
Keywords: CODE GENERATOR 
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03.30 



One-line description: 

bade code gen if local ptr to extrnl strcture is assgn vlu frm extrn ary 

Problem: 

Bad code generated when local pointer to external structure is 

assigned a value from an external array. Example: 

"C" 

"80186" 

$P0INTER_SIZE 32$ 

$FAR_EXTVARS$ 

struct update_msg { char node_id; short neigh_devid[16] ; } ; 

extern int tdb[100] ; 

main() < int temp_devid; struct update_msg *buffer; 

buffer- >neigh_devid[temp devid] = tdb[3]; 
} 

The problem is that ES:BX is set up to point to buffer- >neigh_devid[0] , 
then the value tdb[3] is put in AL, which requires that ES be loaded 
with the segment of tdb. Then the value temp_devid is added to BX, and 
finally ES:BX is used to load AL into what should be 
buffer- >neigh_devid[temp_devid] , but is not. 

Temporary solution: 

Break the equation up into smaller pieces. 

create temp variable holdl of integer type. Then do: 
holdl = tdb[3] ; 
buf f er->neigh_devid[temp_devid] = holdl; 

Signed off 01/14/88 in release Z03.70 



Page: 



SRB detail reports as of 01/14/88 

Number: 1650004705 Product: 8086/8 PASCAL 64814 

Keywords: CODE GENERATOR 

One-line description: 

Using ES register without initalization - REP MOVSB. 

Problem: 

The following programs demonstrates a code generation problem: 

The ES register is used without initalization. 



84 
02.01 



Pointer 


= "Record; 


Record 


= RECORD 




first 




last 




END; 


VAR A, B 


: Pointer; 


BEGIN 




A". last 


:= B'.last 



BYTE; 

ARRAY [0. .40] OF BYTE; 



END. 

The expanded listing shows that the DS and ES registers are 
pushed, then DS is popped. The following REP MOVSB 
instruction does therefore use the contents of the ES 
register, which was never intialized. 



Signed off 01/14/88 in release Z03.50 



Number: 1650018689 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



00.01 



One-line description: 

Stack POP'S exceed Stack PUSH'S when assignment made to ext var. 

Problem: 

The following program loaded character constants into Const_PR0G 
but fails to load the DS segment with the value of the CS segment 
before a REP MOVSB. This instruction requires the source address to 
be in DS and SI and the destination addres to be in ES and DI. 
WHen CS is not equal to DS the program fails. 

"80186" 

$separate_const ON$ 
SEXTENSI0NS 0N$ 
SRECURSIVE 0N$ 
$FAR_LIBRARIES 0N$ 
$POINTER_SIZE 32$ 
$FAR_EXTVARS$ 
$GL0BPR0C 0N$ 

PROGRAM TEST; 

TYPE 



-0 



- -0 
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CHARSET - SET OF CHAR; 


•'8086" 


VAR 


$EXTENSIONS$ 


SET1 : CHARSET; 


TYPE 


SEXTVAR +$ 


INT - SIGNED 16; 


SET2 : CHARSET; 


STRUC = RECORD A : SIGNED 16; 


$EXTVAR -$ 


B : SIGNED 16; 




END; 


BEGIN 


VAR 


SET1 : = ['a' ,'b', 'c'] ; 


$GLOBVAR$ 


SET2 := ['e\'f','g']; 


TABLE CADRAGE : ARRAY [1..12] OF STRUC; 


(* LEA SI,DS:CONST prog+014H *) 


TAB PAR SELEC : ARRAY [1..14] OF SIGNED 16; 


(* PUSH DS *) 


PT TAB PAR SELECT : INT; 


(* missing PUSH CS here *) 


$GL0BVAR 0FF$ 


(* MOV AX.SEG SET2 *) 


$GLOBPROC$ 


(* MOV ES.AX' *) 


PROCEDURE CADRER; 


(* LEA DI,DS:SET2 *) 


VAR 


(* MOV CX.020H *) 


VAL : SIGNED 16; 


(* CLD *) 


BEGIN 


(* POP DS - this should load CS into DS, but instead it loads *) 


FOR PT TAB PAR SELEC := 1 TO 12 DO BEGIN 


{* DS into DS *) 


VAL := VAL * TABLE CADRAGE[PT TAB PAR SELEC]. A; 


(* REP MOVSB *) 


END; 


(* POP DS - nothing on the stack from this procedure to pop *) 


END; 


END. 






compiler puts the limit of the FOR loop in CX 


Temporary solution: 


then moves CX into DX 


No known temporary solution other than identifying the problem 


then moves DX into BX 


and editing manually the ASM8086 file, then assembling the ASM8086 
file. 


but BX has the pointer of the array stored in it. 


Signed off 01/14/88 in release Z03.50 


Signed off 01/14/88 in release Z03.50 






Number: 5000124313 Product: 8086/8 PASCAL 64814 02.01 


Number: 5000103432 Product: 8086/8 PASCAL 64814 02.01 






One- line description: 


One-line description: 


The library routine, DISPOSE, overwrites the ES register 


Incorrect code generated in FOR loop. 






Problem: 


Problem: 


The library routine, DISPOSE, overwrites the ES register with out 


8086/8 Pascal compiler generates incorrect code when an mixed 


restoring it. For example: 


mode arithmatic is done using array elements indexed by a loop 




variable of type BYTE. 


"8086" 




SPOINTER SIZE 32$ 


Temporary solution: 


$FAR LIBRARIES$ 


Use a loop variable of type SIGNED_16. 


$FAR PROC ON$ 



Signed off 01/14/88 in release Z03.50 






TYPE 

A = ARRAY [1. 
REC : "A; 


.6] OF BYTE; 




Number: 5000118844 Product: 8086/8 PASCAL 


64814 


02.00 




Keywords: CODE GENERATOR 






VAR P : REC; 






One-line description: 

Wrong code generated for expression in 'FOR' 

Problem: 

The following program creates bad code: 


loop 




PROCEDURE TEST: 
BEGIN 

NEW (P); 

DISPOSE(P); 
END; 






- -0 
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This problem was also reported on the 6809 (sr# 5000-124065) 

Temporary solution: 

Mo known temporary solution. 

Signed off 01/14/88 in release Z03.50 



Number: 5000134817 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



02.01 



One-line description: 

Incorrect address calculated for beginning of ary in WITH stamnt 

Problem: 

The following program generates incorrect code: 
"processor name" 
$EXTENSIONS ON$ 
PROGRAM TEST; 

TYPE NUM_REC =RECORD NUM_BUF : ARRAY [1..24] OF BYTE; 
T0T_NUM : BYTE; END; 
PTR = "INTEGER; 
VAR KEY: BYTE; NUM_INP : NUM_REC; POINTER: PTR; 

PROCEDURE DISPLAYlROW, COLUMN, LENGTH : BYTE; START : PTR ;) ; EXTERNAL; 

PROCEDURE IN; 
BEGIN 

WITH NUM_INP DO BEGIN 

NUM BUF[TOT_NUM] := KEY; 



ADD 
POINTER: 

MOV 
DISPLAY 
MOV 



BX,AX {BX WILL HOLD ADDR OF TOT_NUM} 

ADDR(NUM_BUF) ; 

DS:WORD PTR DTEST+01AH,BX {Assumes BX contains addr of 

NUM_BUF, IT DOESN'T) 
5, 25-T0T_NUM,T0T_NUM, POINTER) ; 

AL,DS:BYTE PTR [BX+00018H] {also assumes this, wrong!} 



END; 
END; . 

Temporary solution: 

Do not use the WITH statement. Reference all record members directly. 

Signed off 01/14/88 in release Z03.50 



Number: 5000138388 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.00 



One-line description: 

Incorrect code gener. when shift function operand is mult, dimen. array 
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Problem: 

The following code genrates an "1102 - register needed but not 

available" error: 

"8086" 

PROGRAM TEST; 

$EXTENSIONS 0N$ 

VAR TABLE : ARRAY [0. .3,0. . 15] OF SIGNED_8; 

BEGIN 

TABLE[2,3] := SHIFT(TABLE[2, 3] ,4) ; 

END. 

Part of the genrated code looks like: 

MOV CL, #+00004H ; Loads 4 into the counter 
PUSH CX ;Puts 16-bit reg. onto stack 

MOV CH, DS:BYTE PTR DTEST+000023H ;Loads high byte with 

TABLE[2,3] 
POP CX ;Takes 16-bit reg. off stack, 

overrides the address of 
TABLE[2,3] in CH. 
SHL CH.CL ;CH not valid. 

If AL had been used instead of CH, the problem would not occur. 

Temporary solution: 

Use of a dummy variable in the shift function instead of the array 

element will generate the correct code. 

For example: 

"8086" 

PROGRAM TEST; 

{EXTENSIONS ON $ 

VAR TABLE : ARRAY [0. . 3,0. . 15] OF SIGNED_8; 

X : SIGNED_8; 
BEGIN 

X :■= TABLE [2, 3] ; 

TABLE[2,3] := SHIFT(X,4); 
END. 

Signed off 01/14/88 in release Z03.50 

Number: 5000163824 Product: 8086/8 PASCAL 64814 03.01 

Keywords: CODE GENERATOR 

One-line description: 

Multiplication result stored in CX and overwritten when counter reg need 

Problem: 

Incorrect code generated when 80186 Pascal compiler sees this code: 

"80186" 

{EXTENSIONS 0N$ 
PROGRAM TRY; 

CONST COUNT = UNSINGED_8(4) ; 
VAR 
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V : ARRAY [UNSIGNED_8(0) .. ( C0UNT-UNSIGNED_8 ( 1 ) ) ] OF UNSIGNED_16; 

I,X : UNSIGNED_8; 
BEGIN 

X :- UNSIGNED_8!2) ; 

FOR I : = UNSIGNED_8(0) TO (C0UNT-UNSIGNED_8 ( 1 ) ) DO 

V[I] := UNSIGNED_16((UNSIGNED_8(4))*X); < = Incorrect code 

END. generated here! 

See verifier text for details. 

Signed off 01/14/88 in release Z03.50 



Number: 5000171876 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.01 



One-line description: 

Code produces an #1102 error - reg. needed but not available 

Problem: 

The following code produces compile time error #1102 "register needed 
bu not available" for the 80186 Pascal Cross Compiler (compiler rev 
#3.01 and Op Sys rev #2.04). 



"80186" 

$EXTENSI0NS 0N$ 

PROGRAM MISC; 

TYPE 

U_8=UNSIGNED_8; 

U_16-UNSIGNED_16; 

REC1=REC0RD 

A:U_16; 

B : U_8 ; 

END; 



> continued from right column 

VAR 

Rl: ARRAY [U_8(0) . .U_8(l)] OFREC1; 

X : U_8 ; 

PROCEDURE TEST (N:U_8); 

BEGIN 

X:=R1[R1[N].A].A 

END; 



— > continued in left column 

Signed off 01/14/88 in release Z03.50 



Number: 5000171884 Product: 8086/8 PASCAL 

Keywords: CODE GENERATOR 



64814 



03.01 



One-line description: 

BX register gets overwritten when accessing arrays of records 

Problem: 

The following program overwrites the value originally stored in BX 
and then attempts to use BX for the original value. 
See submitter/verifier text for declarations. 

FUNCTION TEST: BOOLEAN; 

BEGIN 

TEST := (U_16(5)*R1[N2[N1]].B) > (U_16(2) *R2[N1].B); 

MUL CL - 
MOV BX.AX 
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MOV AX,#00002H 
MOV BX.DX 



Page: 



90 



*BX register gets overwritten here 
*which did contain 3*N1 
MUL DS:WORD PTR DMISC [BX+OO0AH] *WRONG value now in BX 



END; 



Temporary solution: 

Using the compiler option $AMNESIA ON$ will force the compiler 
to correct this situation. 

OR 
The ASM8086 file can be edited (generated by using $ASM_FILE on$) 
and the line MOV BX,DX can be changed to MOV CX.DX. Also, the line 
CMP BX,AX should be changed to CMP CX.AX. 

Signed off 01/14/88 in release Z03.50 



Number: 5000171900 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.01 



One-line description: 

Contents of register A gets overwritten when accessing mult, arrys of rd 

Signed off 01/14/88 in release Z03.50 

Number: 5000197624 Product: 8086/8 PASCAL 64814 03.01 

Keywords: PASCAL 

One-line description: 

for loop w/ counter = unsignd_8 type uses BX twice 

Signed off 01/14/88 in release Z03.50 



Number: 5000207845 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.00 



One-line description: 

bad code for accessing parameters in nested procedures 

Problem: 

Compiler produces bad code when accessing parameters in nested 

procedures. Register are used twice and address are lost. 

Temporary solution: 

There is no known bug at this time. 

Signed off 01/14/88 in release Z03.50 
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Number: 5000221994 Product: 8086/8 PASCAL 

Keywords: CODE GENERATOR 
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One-line description: 

Using WITH statement and complex record structure causes bad code 

Problem: 

The 8086/8 PASCAL compiler generates code that does not execute 

correctly as documented below: 

FILE TEST5:W0RK 

"80186" 

$extensions on$ 
program tests; 

type 

rectype ■ record 

vail : unsigned_32; 

val2 : unsigned_16; 

val3 : unsigned_16; 

pad2 : array[0. .255] of unsigned_8; 
end; 

var 

reel : array [unsigned_8( 1) . .unsigned_8(4) ] of rectype; 

$list_code on$ 

procedure test (aaa,bbb:unsigned_8) ; 

begin 

with recltaaa] do 
begin 

vail := vail + reel [bbb] .vail; 
val2 := val2 + reel [bbb] .val2; 

mov dx,ds:word ptr [bx+00004h] --- GETS [AAA].VAL2 
mov ax,#+00108h 

mul ex --- STOMPS ON [AAA] .VAL2 

mov si, ax 

add dx,ds:word ptr dtest5[si-00104h] ATTEMPTS TO 

ADD [BBB].VAL2 TO GARBAGE 
mov ds:word ptr [bx+00004h] ,dx 
val3 := val3 + reel [bbb] .val3; 

mov dx,ds:word ptr [bx+00006h] — SAME PR0B. AS ABOVE 
mov ax,#+00108h 
mul ex 
mov si, ax 

add dx,ds:word ptr dtest5[si-00102h] 
mov ds:word ptr [bx+00006h] , dx 
end; 
end. 
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Number: D200019273 Product: 8086/8 PASCAL 64814 ~ Oi.10 

Keywords: RUN-TIME LIBRARY 

One-line description: 

Problem with Pascal 1/0 library (PI0LIB). 

Problem: 

When using the Pascal 1/0 library (PI0LIB), run-time error messages 
are not correctly returned to the 'Abort' routine. The routine 'Perror' 
places the error message into the DATA segment (DS) while 'Abort' 
assumes the message is in the CODE segment. 

Please call your Hewlett-Packard Sales Representative in the event 
you experience this problem. 



Temporary solution: 

No known workaround at this time. 

Signed off 01/14/88 in release Z03.50 



Number: D200022137 Product: 8086/8 PASCAL 
Keywords: RUN-TIME LIBRARY 



64814 



01. 10 



One-line description: 

Real number comparisons may not 'evaluate' correctly. 

Problem: 

Real number comparisons, i.e. >, <, >=, <-, =, may not be evaluated 
correctly with numbers having six (6) or more significant places. For 
example, the following IF statement will NOT be evaluated correctly. 

a := 12.3456; 
b := 12.3455; 
IF a > b THEN 

result := 1 
ELSE 

result := 0; 

In the above example, 'result' will equal '0'. 

Temporary solution: 

No known workaround at this time. 

Signed off 01/14/88 in release Z03.50 



Number: D200023283 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 
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Temporary solution: 

The bugs will disappear if either $amnesia$ is turned on or if the 

first operation is not a 32-bit operation. 


One-line description: 

Illegal PUSH instruction generated. 




- -0 




-0 
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Problem: 

Compiling the following program will cause the compiler to generate 
an incorrect PUSH statement. 

$POINTER_SIZE 32$ 
PROGRAM TEST; 
$EXTENSIONS$ 

VAR 

VARIABLE : INTEGER; 

PROCEDURE PROC_ONE (OFFSET : UNSIGNED_16) ; EXTERNAL; 

BEGIN 

PROCJDNE (UNSIGNED_16(ADDR(VARIABLE) ) ) ; 
END. 

The PROCJDNEf . . . ) statement will cause the compiler to generate a 
PUSH BL Instruction which is illegal. 

Temporary solution: 

This problem appears to be related to the use of 32 bit pointers 
in conjunction with the ADDR function. 

Signed off 01/14/88 in release Z03.50 



Number: D200053710 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.00 



One-line description: 

Var. addresses incorrect inside nested WITH statements 

Problem: 

THE FOLLWOING CODE WAS TAKEN FROM THE PROGRAM LISTED IN THE SUBMITTER 
TEXT. tHE FIRST LINE GENERATES A DIFFERENT VALUE FOR HIGH_BYTE THAN 
THE SECOND TWO LINES. 

DATA_BYTE [SOURCE_MOST_SIGN] := CRCS_10_ADDR [CRCS_10_NUM] .HIGH_BYTE; 

WITH CRCS 10_ADDR [CRCS_10 NUM] DO 
DATA_BYTETSOURCE_M0ST_SIGNT := HIGH_BYTE 

Another example of this problem can be found on Ihplsdsb under 
users/rob in/awabug.s 

Temporary solution: 

Do not use nested WITH statements. 

Signed off 01/14/88 in release Z03.50 
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One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 

"processor" 

PROGRAM BAD_DATA; 



TYPE EVENT 
A 
B 
C 
D 
END; 



RECORD 

BYTE; 

BYTE; 

INTEGER; 

BYTE; 



- -0 



VAR EVENT 1 : EVENT; 



PROCEDURE GENERATORO; 
BEGIN 

EVENT 1 : = EVENT(O) ; 
END; 

BEGIN 
END. 



Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z03.50 



{ THIS ASSIGNMENT RESULTS IN BAD DATA 



Number: D200065060 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.01 



One-line description: 

FOR loop counter gets destroyed when loop includes multiple WITH's 

Problem: 

The following program demonstrates the FOR loop counter 
being destroyed. This problem only occurs if the WITH 
contains at least 3 records and the record IOJJNITS has the 
variable VOLT at least third in the variable list. 

The code generated stores the FOR loop counter into CX, then 
it later moves the counter to DI in preparation for the MOVSB 
instruction for which uses CX. However, MOVSB uses DI as well. 
The counter gets lost when the destination for the string move 
is loaded into DI. 

"8086" PREPROCESS 



- -0 
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PROGRAM TEST; 
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TYPE 

L0D_LIM = RECORD 

MIN_HEAD : REAL; 
END; 
IO_UNITS = RECORD 

G_MW,GJWAR,VOLT : REAL; 
END; 
GEN_LOAD = RECORD 

B_gener_mw : REAL; 
B_volt : REAL; 
END; 

SGLOBVAR ON$ 
VAR 

units : SIGNED_16; 

GEN_CON : ARRAY [1.. 17] OF GEN_L0AD; 

IO_GN : ARRAY [1..17] OF I0_UNITS; 

LL_GN : ARRAY [1..17] OF LOD_LIM; 
$GLOBVAR OFF$ 

PROCEDURE BUFFER_DATA; 
BEGIN 

FOR units := 1 TO 17 DO 

{MOV CX,#+11H - loads ex with 17} 
BEGIN 
WITH GEN_C0N [units] ,LL_GN[units] , 

{MOV AX.CX - counter now in ax} 
I0_GN[units] DO 

{MOV CX,AX - counter moved back into CX} 
BEGIN 

B_volt :- VOLT; 

{MOV DI.CX - moves counter into DI} 
{MOV CX, #4H - destroys contents of ex} 
B_gener_mw := G_MW; 

{LEA DI .memory loc - destroys counter in DI } 
END {WITH}; 
END {FOR}; 

{MOV CX,DI -loads counter back into ex, but counter} 
{ isn't in DI} 
{LOO? - decrements counter} 
END {BUFFER_DATA}; 

BEGIN 

BUFFER_DATA; 
END. 



Temporary solution: 

The temporary solution requires that an IF statement be added 

to the BUFFERDATA procedure. 



Change: WITH GEN_C0N [units] ,LL_GN[units] , 
I0_GN [units] DO 
BEGIN 
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B_volt := VOLT; 

To: WITH GEN_CON[units],LL_GN[imits], 

I0_GN[units] DO 
BEGIN 

IF (1-1) THEN X :- TRUE; 

{x must be declared as a boolean variable} 

B_volt : = VOLT; 

Signed off 01/14/88 in release Z03.50 
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Number: D200068759 Product: 8086/8 PASCAL 

One-line description: 

WITH construct causes wrong offset 



64814 



03.02 



Problem: 

The examples for this problem have been given to the lab (file 

Problem3) 

When using the WITH construct, the compiler calculates the correct 
offset for the variable in the FOR statement, but it fails to save 
the segment part of the pointer. Later it loads in a random number 
as this segment address. This only occurs when the IF statement is 
inside the WITH statement. 



"80186" PREPR0CESS 
SEXTENSIONS 0N$ 
SRECURSIVE 0N$ 
$POINTER_SIZE 32$ 
$FAR_LIBRARIES 0N$ 
$FAR_PROC 0N$ 
$SEPARATE_CONST 0FF$ 

PROGRAM CC_ANALYSIS_JOb; 

CONST 

MAXINT - 32767; 

Addr_min • 

Addr_max = 8; 

Analys_b_no = UNSIGNED16U96) : 

Analys_res - UNSIGNED _16(197); 

TYPE 

INTEGER = SIGNED_16; 

Time_type - UNSIGNED _16; 
#DEFINE ORD INTEGER; 

TYPE 
que_type = ( timer_que, event_que); 
Ptr = INTEGER; 
Pid = RECORD 

dma : BYTE; 

process : INTEGER; 

END; 
Signal_p - ^Signal; 
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Event_type = UNSIGNED 16; 




IF Len - 






Addr type = RECORD 










Len : BYTE; 




MOV DS:W0RD PTR DIA5_converted+00006H,SI 






Adrtype : BYTE; 




{but does not save segment} 






Digits : ARRAY [Addr min . . Addr max] OF CHAR; 










END; 




THEN IA5 converted := FALSE; 






User_cat = ( No_bar, Bar 1, Bar_2); 




ELSE FOR i := 1 TO Len DO 






e_Analys_b_no = RECORD 




CASE Digits[i] OF 






Dest_addr_type; 










Cat : User cat; 




LES BX,DS:WORD PTR DIA5_converted+0006H 






END; 




{this loads garbage into ES} 






Ana_res_type = (Next_digit,Local_call,No T Convert, 




, 0', , l*,' 2\ '3' ,'4' ,'5' .'6' ,'T , '8', '9' 

: Analys_no[i] : = BYTE(Digits[i] - 






Outgoing call, Invalid digit); 




0*); 




Signal = RECORD 




'*' : Analys_no[i] 


- 10 








Link, Backlink : Signal_p; 




'#' : Analys_no[i] 


= 11 








Que : que_type ; 




'A' : Analys_no[i] 


- 12 








Duration : Timer_type; 




'B' : Analys_no[i] 


- 13 








Address, Sender : Pid; 




' C : Analys_no[i] 


= 14 








CASE Event : Event type OF 




'D' : Analys no[i] 


= 15 








Analys b no : TAnalys b no e : e Analys b no); 




END; 






END; 




Analys li : = sig''. Analys b no e.Dest adr.Len; 






Analysis_?.esult = RECORD 




END; 











Result : Ana_res_type; 
CASE Ana_res type OF 

Next_dTgit : (Ana_index, dummy 1 : BYTE); 
Local_call : (Nult_no :UNSIGNED_16) ; 
No_convert : (Conv_index,dummy2 : BYTE ); 
Outgoing_call : (Rout_index,Bar_c:BYTE) ; 
Invalid_digit : (dummy3 : INTEGER); 
END; 
Mo_sub_table = ARRAY [0..15] OF Analysis_result; 
Table_p = ~No_sub_table; 

Conv_type = (Replace_no,Delete_digits, Add_digits,Del_and_add) ; 
Conv_elements - RECORD 

Conversion : Conv_type; 
Del_position : BYTE; 
Number of del : BYTE; 
Add_positTon : BYTE; 
Number of_add : BYTE; 
Newe_dTgits : ARRAY [1..15] OF CHAR; 
END; 

VAR 

sig : Signal_p; 
i : BYTE; 

Analys_li : BYTE; 

Analys_no : ARRAY [1..15] OF BYTE; 

$RECURSIVE 0FF$ 

FUNCTION IA5_converted : BOOLEAN; 
VAR 

i : BYTE; 

BEGIN 

IA5_convertede := TRUE; 

WITH sig",Analys_b_no_e,Dest_adr DO 

- -0 



BEGIN 
END. 

END; 
END; 

BEGIN 
END. 

Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release 203.50 

Number: D200058767 Product: 8086/8 PASCAL 64814 03.02 

One-line description: 

With construct causes wrong offset 

Problem: 

The examples for this problem have been given to the lab (file 

Problem4) 

An globally ORGed variable is accessed inside a Procedure using 
a WITH construct. The array offset is calculated and stored in 
the AX register. It is then moved to the BX register. When the 
offset is changed, the code access the AL register instead of the BX 
register. Hence, the wrong offset into the array is calculated. 

This problem does not occur when the variable is load to the 
procedure. 

"80186" PREPROCESS 
SEXTENSIONS 0N$ 
SRECURSIVE 0N$ 

- -0 
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$POINTER_SIZE 32$ 
$FAR_LIBRARIES 0N$ 
$FAR_PR0C 0N$ 
$SEPARATE_CONST 0FF$ 

PROGRAM WITHTEST; 

CONST 

MAXINT = 32767; 

TYPE 

INTEGER = SIGNED_16; 
#DEFINE ORD INTEGER; 

TYPE 

Tilst_txt_lintyp = RECORD 

Pos_L : BYTE; 

Pos_H : BYTE; 

Li * BYTE* 

Txtstring': ARRAY [1..42] OF BYTE; 

END; 

Tilst_txt_element = RECORD 

Tilst_txt_lin : ARRAY [1..2] OF Tilst_txt_linty 

p; 

END; 



Tilst_txt_type = ARRAY [0..16] OF Tilst_txt_element; 



VAR 



$ORG 20000000HS 

X :BYTE; 
$END_0RG$ 

$EXTVAR 0N$ 

Tilst_txt : Tilst_txt_type; 

SEXTVAR OFF$ 
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END; 

BEGIN 
END. 

Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release Z03.50 
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Number: D200075952 Product: 8086/8 PASCAL 



64814 



03.02 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

{EXTENSIONS 0N$ 

PROGRAM D0L00P; 



VAR SECTORNUM, STOPSECTOR 
A 



: UNSIGNED_8; 

: INTEGER; 



BEGIN 

STOPSECT0R := UNSIGNED 8(247) 



FOR SECTORNUM 

A := 5; 
END; 



UNSIGNED 8(0) TO ST0PSECT0R DO BEGIN 



PROCEDURE FAST_TXT_TILST(Tilst_txtnr,Linie_ofset : INTEGER); 


END. 


VAR 

N : INTEGER; 

{ X : BYTE; makes the problem go away } 

BEGIN 

WITH Tilst txttTilst txtnr] DO 
BEGIN 

FOR N :- 1 TO 2 DO 
BEGIN 

X := Tilst_txt_lin[N].Pos_l; 


Temporary solution: 

USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 

"PROCESSOR" 
{EXTENSIONS 0N$ 
PROGRAM D0L00P; 


SUB - AL,#+002DH (shold be SUB BX,#+002DH) 

END; 
END; 


VAR SECTORNUM, ST0PSECT0R : UNSIGNED 16; 
A : INTEGER; 


- -0 


- -0 
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BEGIN 

STOPSECTOR := UNSIGNED_16(247) ; 

FOR SECTORNUM := UNSIGNED_16{0) TO STOPSECTOR DO BEGIN 

A := 5; 
END; 
END. 

This works for values up to 8000H. 
Signed off 01/14/88 in release Z03.50 



Number: D200077875 Product: 8086/8 PASCAL 



64814 



03.02 



One-line description: 

$RECURSIVE $ option defaults to incorrect mode (OFF) 

Problem: 
"80188" 

PROGRAM ERROR; 
PROCEDURE ERR_3; 

VAR A,B : SINGED_16; 
BEGIN 
A:= B; 

MOV AX,DS:W0RD PTR DERR_3+0002H 
MOV DS:W0RD PTR DERR_#, AX 
ERR_3; 

CALL FAR PTR ERR_3; 
END; 

The $RECUSRSIVE$ option should default to ON, but instead defaults 
to OFF. 



Temporary solution: 

Use explicit Directive in program. 

Signed off 01/14/88 in release Z03.50 



Number: D200078642 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.00 



One-line description: 

pointers passed as procedure parameters not fully dereferenced. 

Problem: 

When passing a pointer to a pointer to a record, the pointer is not 

fully dereferenced. See verifier text for example. 

SEXTENSIONS 0N$ 
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$SEPERATE_CONST 0FF$ 
SSEPARATE 0N$ 
$FAR_PR0C 0N$ 
SGLOBPROC ON$ 
$FAR_LIBRARIES $ 
$POINTER_SIZE 32$ 
$FAR_EXTVARS$ 
SRECURSIVE 0N$ 
S0PT0MIZE 0N$ 
$DEBUG OFF$ 
$I0CHECK 0FF$ 
$FULL_LIST 0FF$ 
$LIST_C0DE 0FF$ 
$LIST_OBJ OFF$ 

PROGRAM Error_15; 

TYPE 

ARTIKEL = RECORD 

ELE1 : SIGNED_16; 

ELE2 : SIGNED_16; 

END; 
ARTIKEL_PTR = "ARTIKEL; 

PROCEDURE ART_DEFAULTS(VAR ART : ARTIKEL); 

BEGIN 

END; 

{this is the problem routine) 

PROCEDURE ERR_15(VAR ART : ARTIKEL_PTR) ; 

BEGIN 

ART_DEFAULTS ( ART" ) ; {< this generates the following error code} 

PUSH SS: [BP+0000AH] 

PUSH SS: [BP+00008H] 

CALL FAR PTR ART_DEFAULTS 

{The variable art" was never fully dereferenced. It now points at 
a pointer to ARTIKEL, not at ARTIKEL} 

END; 



Temporary solution: 

PROCEDURE W0RK_15(VAR ART : ARTIKEL_PTR) ; 

VAR 

A : ARTIKEL_PTR; {this solution will fully dereferene the pointer} 
BEGIN 

- -0 
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A := ART; 

ART_DEFAULTS(A'"); 

END; 

Signed off 01/14/88 in release Z03.50 
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Number: D200079194 Product: 8086/8 PASCAL 
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03.02 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 

changes physical size), when it should generate a fatal error. It 

tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPR0CESS 
"6809" 

{ Test program to demonstrate Pascal language defect } 
{ Functional type change of constant to multi-byte variable } 
PROGRAM PTEST101; 
SEXTENSIONS ON$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR event 1: event; 
i: INTEGER; 
R: REAL; 

BEGIN 

{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 

eventl := event(O); {This code is incorrect Pascal} 



- -0 
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{Correct Pascal using individual assignments} 

eventl. type :=0; 

event l.qual if ier:=0; 

eventl.msg:=0; 

eventl. send_task: -0; 
END. 



Signed off 01/14/88 in release Z03.50 
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Number: D200079251 Product: 8086/8 PASCAL 
Keywords: PASS 1 
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03.02 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



$EXTENSI0NS 0N$ 
PROGRAM PTEST; 



VAR 

S8 
U8 
S16 
U16 

BEGIN 
U16 
U16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



UNSIGNED_16(S8) ; (* signed extension of S8 - correct *) 
UNSIGNED_8(S8) ; (* signed extension of S8 - incorrect *) 



END. 



S16 :■= SIGNED_16(U8) ; 
S16 := SIGNED_8(U8); 



(* unsigned extension of U8 - correct *) 
(* unsigned extention of U8 - incorrect *) 



Signed off 01/14/88 in release Z03.50 



- -0 
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Number: 5000121830 Product: 9900/0 ASSEMB 

Keywords: CODE GENERATOR 
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One-line description: 

Auto increment with indirect addressing does not assemble correctly. 

Problem: 

THE HOSTED 9989 ASSEMBLER/LINKER ON THE 9000 DOES NOT ASSEMBLE 

CORRECTLY WHEN THE CUSTOMER USES THE INDIRECT ADDRESSING WITH 

AUTOINCREMENT. THE CODE DOES ASSEMBLE CORRECTLY ON THE 64000. 

EXAMPLE: 

MOV R11,*R7+ 
AND 

INC *R6+ 

GENERATES THE ERROR MISSING OPERATOR, AN ARITHMETIC OPERATOR WAS 
EXPECTED AND WAS NOT FOUND ON THE HOSTED SOFTWARE. 

Temporary solution: 

There is no know work around at this time. 

Signed off 01/14/88 in release Z01.80 



Number: 5000232959 Product: 9900/0 ASSEMB 
Keywords: CODE GENERATOR 



64847 



00.00 



One-line description: 

Froblem with negative displacementwith SBO SBZ instructions. 

Temporary solution: 

All constants have a 32 bit internal representation. When negative 

numbers need to be reprsented, the following syntax should be used: 

SBO 0FFFFFFFFFH 

When the used does not put 8 F's, the system sign extends the high 
order bytes, and interprets the number as positive 255, outside the 
legal range for this instruction. 

Signed off 01/14/88 in release Z01.80 

Number: D200035220 Product: 9900/0 ASSEMB 64847 00.46 

One-line description: 

In macros, "" and '' are not equivalent. 

Problem: 

In macros, "" and ' ' are not equivalent, but should be as defined in 

the manual. 

Signed off 01/14/88 in release Z01.80 
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Number: 5000224022 Product: F9450 EMULATION 



64286 
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01.04 



One-line description: 

Answer to "Emulate SCR?" is automatically changed to 



yes 



Problem: 

If the emulator is configured for 17 bits of address or greater, 
and the user modifies the memory configuration, then the 
configuration setting of "emulate the system configuration 
register" is set to "yes" even if the user had previously set 
the response to "no" . 

Temporary solution: 

If you don't want to emulate the SCR, and you are using 17 bits 
of address or greater, then you must always check the answer to 
"emulate system configuration register?" to be sure that the 
answer is "no". 

Signed off 01/14/88 in release Z01.05 

Number: 5000164004 Product: F9450 EMULATION 54286 

Keywords: ENHANCEMENT 

One-line description: 

Cannot single step through a Software Breakpoint 

Problem: 

It is not possible to single step through a Software Breakpoint 
and have the breakpoint actually function properly. If you 
step the BEX code, you end up single stepping the monitor 
code itself at the Software Break Entry location. Since the 
monitor is not re-entrant, this causes some minor problems. 
The biggest problem is that the user's registers and IC get 
lost since the monitor itself uses some of the registers. 

This problem occurs most often when the user has multiple 
software breakpoints set. The user encounters a software 
breakpoint while running, then decides to single step the 
code at the breakpoint location. The user then accidentally 
single steps the BEX code itself and finds himself stepping 
the emulation monitor code. 



Temporary solution: 




men pciiuim me =>xiig±c Mcpping unat i& ucsiicu. 

restore all of the breakpoints, just enter "modify 

sof tware_breakpoints set" before using the "run" command. 

Signed off 01/14/88 in release Z01.05 



01.03 
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Number: D200066357 Product: F9450 EMULATION 

Keywords: ENHANCEMENT 



64286 
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01.03 



One-line description: 

MASK, STATUS, and IC are not always cleared when running from reset. 

Problem: 

When you enter the monitor from a hardware reset, the MASK, 
STATUS word, and Instruction Counter contain the values that 
existed at the previous break entry into the monitor. These 
three registers should be cleared when running in the monitor 
from a reset condition since the F9450 cpu will clear the 
same registers after a reset. Note that the values are 
initialized to zero in the assembly code for the monitor, but 
there is no code that actively resets the values to zero upon 
entering the monitor at the RESET_IN location. 

Signed off 01/14/88 in release Z01.05 



Number: D200068957 Product: F9450 EMULATION 
Keywords: ENHANCEMENT 



64286 



01.04 



One-line description: 

Enhance the register display to show the Pending Interrupt Register 

Problem: 

The current register display does not show the Pending Interrupt 

Register. 

Temporary solution: 

A good temporary implementation of this enhancement can be made 
by the user of the F9450 emulator. The emulation monitor can 
be modified such that the PIR is displayed in place of the 
Fault Register. All that is necessary is a small modification 
to the F9450 monitor program so that the PIR is stored in the 
memory location where the Fault Register is now stored. 

To implement this idea, replace the instruction XI0 R14.RCFR 
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Number: 1650019257 Product: HOST SOFTWARE / VAX 64882 01.20 

One-line description: 

VAX help on MAPBUS command causes system error 

Problem: 

Digital VMS help command gives an access violation when part of a 
keyword is entered and the help file has a blank line after the 
keyword. The MAPBUS help entry has a spurious blank line after the 
MAPBUS keyword. 

Temporary solution: 

Delete spurious blank line after MAPBUS keyword in help file. 

Signed off 01/14/88 in release Z02.30 



Number: D200069104 Product: HOST SOFTWARE / VAX 64882 



01.70 



One-line description: 

64100 cluster disk free list is corrupted so there is not enough space 

Problem: 

The HSL seems to destroy the free page list during operatino. 
Transfer reports no space available to transfer the file. 
Directory reports no space available. Directory of all user ids 
shows that the disk has a significant portion remaining. (+20%) 
This appears to be happenning at 4 sites. One site has sent 
me an image backup made after the problem occurred. This is 
probably just a VAX HSL link problem. 

Temporary solution: 

SOFT FIX will generally repair the problem, or at least indicate any 

exceptionally large files on the disk. These files can then be purged. 

Signed off 01/14/88 in release Z02.30 

Number: D200082669 Product: HOST SOFTWARE / VAX 64882 02.00 

Keywords: TRANSFER 



with the instruction XIO R14.RPIR in the "UNLOAD" section 
of the monitor, MON_9450 : HP: source. 

Signed off 01/14/88 in release Z01.05 


One-line description: 

CSIB process does not come up on system bootup 

Problem: 

CSIB process does not come up on system boot-up. The following error 




message is seen on the system console: 

CSIBx: unable to connect to HSL driver, check installation. 

This is an intermittent problem, and rebooting the system can work. 

Temporary solution: 

Try rebooting the system until the CSIB process comes up. 

Signed off 01/14/88 in release Z02.30 


- -9 


- -0 
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Number: D200082636 Product: HOST SOFTWARE / 300 64883 01.00 

One-line description: 

Transfer does not handle imbedded linefeeds in binary files. 

Problem: 

Transfer software not capable of handling imbedded linefeeds in binary 

files. 

Signed off 01/14/88 in release 201.10 
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Number: 1650018721 Product: HOST SOFTWARE / 500 64880 01.60 

One-line description: 

Debug file transfers may not function with 14 character file names. 

Problem: 

Debug file transfer may not function correctly when 14 character file 
names are used during program development. As an example, consider 
the following: 

1) create a source file with a 14-character filename 
(i.e., "source7890ab.C" ) and compile 

2) link the relocatable file and create an absolute 

filename of the form "source7890ab.X") 

3) transfer the data to a 64000 system using the 
command 

$ transfer -thda source789ab.L :TMP 

Transfer will report problems with one of the temporary files 
which transfer created. 

Signed off 01/14/88 in release 201.80 

Number: 5000219204 Product: HOST SOFTWARE / 500 64880 01.06 

Keywords: TRANSFER 

One-line description: 

Bad file format does not cause error in transfer. 

Problem: 

The transfer software will successfully transfer files with 
formats that are not supported. For example, an absolute file 
with records greater than 256 bytes will successfully transfer. 
However, this file will cause unpredictable problems on the 
destination system. 

The example given is a file transfered from 500 to 64000. This 
transfer completes successfully. When the file is transfered 
back to the 500, an error is generated and the transfer is not 
complete. The error gives no indication that the file format 
is wrong. 

Temporary solution: 

To insure the successful transfer and usability of files, 
the users should use the utility read64 on files to be 
transfered. This utility will indicate the size of the 
records in the files. For a description of the format of 
absolute files, see manual 64880-90903. 

Signed off 01/14/88 in release 201.80 



- -0 



- -0 
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Number: D200019265 Product: HOST SOFTWARE / 500 64880 01.10 

One-line description: 

Invalid file names are not detected by the transfer utility. 

Problem: 

When constructing the transfer command as a one line command, the 
transfer software does not verify the syntax of the 64000 file name 
before sending the command to the 64000. The result is a syntax error 
on the 64000 for invalid file names. 

Signed off 01/14/88 in release 201.80 



SRB detail reports as of 01/14/88 

Number: 1650006908 Product: OPERATING SYSTEM 

Keywords: DC600 



64100 
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00.01 



One-line description: 

64000 backup from 7946 to 9144 with 150" tape produces wrong message. 

Problem: 

Backup to a 9144 tape drive and using a tape that is too small 
for the disc, i.e. a 150' tape, will produce an incorrect message: 
"Disc and DC600 units must be at the same controller address" 

Temporary solution: 

Multi-tape backups to a 9144 are not currently supported on the 

64000 system. 

Signed off 01/14/88 in release Z02.10 

Number: 1650033209 Product: OPERATING SYSTEM 64100 02.07 

One-line description: 

Unique label is flagged as undefined in macro expansion. 

Problem: 

Using labels in macro causes incorrect error message 

Error-ML - Macro Label, Label not found within macro body. 

"68000" 

REGMEMS MACRO &INST ,&FPM,&EA,MX 

.IF "MX" .EQ. """ LLLL1_&&&& 

M0VE.L D0.D1 
LLLL1_&&&& M0VE.L D1.D0 
NUL_REL TST.B D7 

MEND 

The errors occur in the maocro calls within the main program: 

*Main Program 

REGMENS FMOVE.FPO.Dl 
.IF " .EQ. "" LLLL1_0001 

ERROR-ML 



Temporary solution: 

No temporary solution known at this time. 

Signed off 01/14/88 in release Z02.10 

Number: 5000111666 Product: OPERATING SYSTEM 



64100 



02.01 



One-line description: 

Formatting a floppy from a command file sometimes is unsuccessful. 

Problem: 

When the 64941 floppydrive is used to initialise a floppy from a 

- -P 
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command file, it first shows a number of retries, than it seems to 
format but at the end 'System area on disc bad: format failed' 
is displayed. 

Formatting by giving the command manually, always goes well. 
Formatting from a command file sometimes goes well but mostly not. 
The floppy used was a 'XIDEX' precision flexible disk. 

Temporary solution: 

A temporary solution is to put something in the command file to delay 
execution of the next command until the drive has finished initial- 
ization. 

Signed off 01/14/88 in release Z02.10 



Number: 5000181552 Product: OPERATING SYSTEM 
Keywords: DC600 



64100 



02.04 



One-line description: 

No multi-tape backup strategy for discs > 64MB on the 64000. 

Signed off 01/14/88 in release Z02.10 



Number: 5000189985 Product: OPERATING SYSTEM 



64100 



02.07 



One-line description: 

Instructions assembling differently than previous assembler. 

Problem: 

TWO INSTRUCTIONS ASSEMBLE DIFFERENTLY THAN THEY DID ON A PREVIOUS RELEAS 

E. THIS WOULD REQUIRE CHANGING A GREAT DEAL OF CODE. 



FOR MACROS 



IF LABLE.EQ.LABLE2 

NOW GIVES ERRORS UNLESS BLANKS ARE ADDED ON EACH SIDE 
OF . 

IF LABLE . EQ . LABLE2 



FOR REFERENCES OF THE TYPE [A1.D3.L] THERE IS NOW AN ERROR POINTING TO 
THE .L WHICH SAYS MISSING OPERAND. 



Temporary solution: 

No temporary solution known at this time. 

Signed off 01/14/88 in release Z02.10 



Number: 5000202770 Product: OPERATING SYSTEM 

One-line description: 

Logical operators generate MO error. 



64100 



02.06 



Problem: 

All assemblers generate Missing Operand error at logical operator. 

For example the .NE. operator will generate an error. 



-P 
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Temporary solution: 

Reload operating system 2.05. 

Signed off 01/14/88 in release Z02.10 
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Number: D200027953 Product: OPERATING SYSTEM 
Keywords: COPY 



64100 



02.01 



One-line description: 

"copy f:link_com to display" doesn't display all attributes of "f". 

Problem: 

Link a file with list, xref, overlap_check, and comp_db on. Then, when 
one does "copy f ile: link_com to display", only the values for map and 
xref appear. 

Temporary solution: 
None at this time. 

Signed off 01/14/88 in release Z02.10 



Number: D200062604 Product: OPERATING SYSTEM 



64100 



02.04 



One-line description: 

Comment is taken as a parameter when a null parameter is passed. 

Problem: 

If you invoke a macro with a null parameter and a comment 
is included on the line, the comment will be taken as 
the parameter (even with a semi-colon). 



"68000' 
X 

DONE 



MACRO 

.IF 

MOVE 

.NOP 

MEND 

X 
X 
END 



&PARM 

"&PARM-.EQ. 
#3, DO 



DONE 



HI 



;THIS COMMENT WILL BE A PARAM. 



Temporary solution: 

No work around at this time other than not placing comments 

on the macro invokation line. 

Signed off 01/14/88 in release Z02.10 



-P 
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Number: D200085050 Product: OPERATING SYSTEM 



64100 



Page: 115 

02.07 



One-line description: 

Phase error incorrectly reported on 64000 and hosted assemblers. 

Problem: 

The 1750 assembler reports a spurious error message PH_ERR (Phase 
error) due to the usage of C0UNTER_UPDATE vs. GEN_C0DE in passes 1 
and 2 of the assembler. 

Cause: 

This defect has been fixed and this report is 
being submitted for QA release purposes. 

Temporary solution: 
None At this Time. . . 

Signed off 01/14/88 in release Z02.10 
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Number: 5000223792 Product: TMS 32010 MODULES 



Page : 



64285 



116 
01.00 



One-line description: 

Inverse assembly for 1E91H is incorrectly shown as SUB *-, 

Problem: 

The instruction code 1E91H should be inverse assembled to 

"SUB *-, E,l" but instead is displayed as "SUB *-, E,0" 

Temporary solution: 

Until this problem is fixed, you can verify whether the 
inverse assembly is correct by examining the code itself. 
1E91H is the code for SUB *-, E, 0. 

Signed off 01/14/88 in release Z01.02 
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Number: D200081620 Product: USER DEF ASSEMB 500 64851S001 01.60 

One-line description: 

expressions of the form 123456.78 cause errors 

Problem: 

There is a problem with the expression handler on the hosted software 
when parsing expressions of the form 12345.67, which the assembler 
thinks is a real number. This problemis shown in sample code supplied to 
Dave Ritchie by JLO in conjunction with the 64180 assembler. 

Signed off 01/14/88 in release Z02.10 
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Number: D200081638 Product: USER DEF ASSEMB VAX 64851S003 01.60 

One-line description: 

expressions of form 123456.78 cause errors 

Problem: 

There is a problem with the expression handler on the hosted software 
when parsing expressions of the form 12345.67, which the assembler 
thinks is a real number. This problemis shown in sample code supplied to 
Dave Ritchie by JLO in conjunction with the 64180 assembler. 

Signed off 01/14/88 in release Z02.10 



-S 



-s 
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Number: 5000241562 Product: USER DEF EMULATION 64274 01.05 

One-line description: 

run until <addr> fails from reset when reset points to user code. 

Problem: 

If the reset vector points to user code, the command "run until 
<addr>" from a reset state may not work correctly. The expected 
result is that the emulator will start executing user code and 
when the address is found by the analyzer, a break into the monitor 
will occur. 

What may happen is that the emulator will break into the monitor 
as a result of the analysis break from the "run until <addr>" 
command. Following this, an "exit monitor" command is given and 
the emulator starts running user code again without an analyzer 
break pending. The condition that will cause this command to work 
incorrectly is that the "until" address must not be accessed 
within approximately 30 mS of the release from reset. 



The generic algorithm that the UDE software uses for a 
<addr>" command is as follows: 



'run until 



1) The analyzer is set up with the break condition for the until 
address and it is then started. 
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This command file performs exactly the same function as 
"run until <address>". It is invoked by typing 

RU xxxx 

where xxxx is the "until" address. 

Signed off 01/14/88 in release Z01.06 

Number: D200043828 Product: USER DEF EMULATION 64274 01.04 

One-line description: 

Bad display of trace data with 8-bit UDE 

Problem: 

With 8-bit UDE emulators, the trace, when displayed, gives the wrong 
data at odd addresses. What is seen in the trace is the same data in 
the odd address as was captured for the preceeding even address. Note 
that this problem is only with version 1.04 of the UDE software, the 
previous version 2420 does not exhibit the problem. 

Temporary solution: 

Changing the UDE Configuration file parameter "0PC0DE_SIZE" 
to WORD will partially solve this problem. Changing the 
parameter to WORD, should allow the internal analyzer to 



2) The processor is released from reset. 

3) An ARE_YOU_THERE monitor command is executed by the host to 
determine if the emulator is running in the monitor or running 
user code. 

4) If in the monitor, an EXIT monitor command is given. No test 


display each data field, however, the data will be visually 
offset on the HP64000 display. Changing the "0PC0DE_SIZE" 
to equal WORD may adversely affect the inverse assembly of 
opcodes during single-stepping. 

Signed off 01/14/88 in release Z01.06 


is made to determine if the break condition occurred to get into 
the monitor. 

If running user code, nothing is done. 
The incorrect behaviour is caused by step 4. Since there is no 


Number: D200046623 Product: USER DEF EMULATION 64274 01.04 

One-line description: 

modify memory starting at odd addresses does not always work 

Signed off 01/14/88 in release 401.06 


test to determine if the analyzer break caused entry into the 
monitor, the emulation software assumes that it must exit to user 
code so it issues the EXIT command when it should not. 

Temporary solution: 

A very reliable and easy to use workaround can be set up with a 
command file. In a command file called RU (for "run until"), 
put the following instructions. 

&PARMS ADDRESS 

trace before &ADDRESS break_on trigger 

run 

- -S 


- -S 
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Number: 1650036525 Product: USER INTERFACE 300 64808S004 01.20 

One-line description: 

Pmon flags a syntax error when attempting to append files 

Problem: 

pmon flags a syntax error for 

cat file >;> file2 

But this a valid command and necessary to append i. e. a reloc file 
to a library. 

Temporary solution: 
Workaround: 

Use 

!cat file >> file2 

In this case however the pmon softkeys can't be used. 

Signed off 01/14/88 in release Z02.10 

Number: 1650038521 Product: USER INTERFACE 300 64808S004 02.00 

Keywords: MENUS 

One-line description: 

Pmon command completion via shell variables not working correctly 

Problem: 

Pmon generates collision errors in command completion between the 
external shell variables (whether set externally or by internal default) 
and the "default" pmon commands when they are the same. 

The problem appears with all commands controlled by external shell 
variables. 

Example: PMON_C0MPILE not set, default pmon compile is "comp". If the 
user types co<tab>, pmon should complete to "comp". However, the error 
ERROR: possible tokens: comp, comp is generated. 

Signed off 01/14/88 in release Z02.10 



Number: D200077495 Product: USER INTERFACE 300 64808S004 

One-line description: 

User softkey display should be erased after shell escape. 

Problem: 

Display needs to be cleaned up when executing certain commands. 

In one case the softkeys need to be erased before going on. 

Signed off 01/14/88 in release Z02.10 



- -S 



01.20 
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Number: D200080135 Product: USER INTERFACE 300 64808S004 



01.20 



One-line description: 

pwd truncates the /net/system portion of the path when RFA'ed to system. 

Problem: 

When using the HP 64000-UX products and netunaming across the LAN 
to another system, such as a compile server, the HP-UX command 
"pwd" which is used by the HP64000-UX product to tell what the 
local directory is, truncates the "/net/system" part of the path. 

This is a HP-UX operating system defect. It is not a defect in 
the HP 64000-UX application software. As soon as this defect is 
fixed in HP-UX, it will work correctly when using the HP 64000-UX 
applications. 

Signed off 01/14/88 in release Z02.10 

Number: D200080721 Product: USER INTERFACE 300 64808S004 01.20 

One-line description: 

Pmon command completion intermittantly fails after completion error. 

Problem: 

Pmon evidently sets a flag on a command completion error which 
inhibits further errors on the same completion. Once the user 
types more characters and/or starts a new command, the flag should 
be reset such that new completion requests will be processed. 

Unfortunately, the flag is not consistently reset, so command 
completions after a completion error will intermittantly have 
no effect. 

Temporary solution: 

Use softkeys or, when command completion fails with no message of 
any kind, add more characters of command and try again. Most 
errors occur only at the one or two character level. 

Signed off 01/14/88 in release Z02.10 



Number: D200081141 Product: USER INTERFACE 



300 64808S004 



01.20 



One-line description: 

Command search algorithm should match the softkey package. 

Problem: 

Pmon will not properly execute a command file which is not 

in the current directory. If the command file is in the search 

path specified in the PATH variable, a shell is forked to execute 

the command file. The shell will refuse to execute the command 

file, presumably since pmon command files are not executable. 

Temporary solution: 

Use only command files which are in the current directory. 

Signed off 01/14/88 in release Z02.10 

- -S 
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Number: 5000170654 Product: Z80/NSC800 C 64824 01.03 

One-line description: 
Error using switch (*x++). 

Problem: 

The following program hangs during complation on the 64100 and flags an 
error on the 9000/500 hosted compiler. The 64100 displays "STATUS: comp 
iling C/Z80 in pass 2 Line #8, Errors=0". The error message from the 90 
00/500 is "line #8 -- pass 2 error #1006, 1006: Compiler Error. Contact 
Hewlett Packard. The program is as follows: 

"C" 

"Z80" 

/* program with switch problem */ 

main! ) 

{ 

char *chrptr,*chrptr2; 

*chrptr='a' ; 

switch (*chrptr++) { 

case 'a' : 

*chrptr='z' ; 

case 'b': 

*chrptr='y' ; 

} 
} 

Temporary solution: 

The work around is to break the switch(*chrptr++) into two statements. 

The first is switch(*chrptr) and then after the switch statements do a 

*chrptr++. 



Signed off 01/14/88 in release Z02.10 
Number: 5000172825 Product: Z80/NSC800 C 



64824 



01.03 



- -S 



One-line description: 

RETI is not generated when exiting an interrupt procedure. 

Problem: 

When using $INTEHRUPT 0N$ the compiler does not generate the RETI 
instruction of the Z80 microprocessor. This is crucial when designing 
with such Z80 peripheral chips as the Toshiba Z84C30 Counter/Timer 
because the chip expects to see this instruction inorder to terminate 
its interrupt cycle. If the compiler is going to push all of the 
registers when using $INTERRUPT ON$ then why not use the correct 
instruction when returning from the interrupt. One other point to be 
made is that the Z80 emulator 64253A takes into consideration this 
peripheral requirement when emulating out of emulation memory by 
enabling output buffers during emulation memory read cycles. 

Signed off 01/14/88 in release Z02.10 



-8 
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Number: 5000173278 Product: Z80/NSC800 C 
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One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 

"C" 

"280" 

char array[12]; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASM_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 01/14/88 in release Z02.10 



Number: 5000231605 Product: Z80/NSC800 C 



64824 



01.04 



One-line description: 

+■ operator does not work for pointers to structures. 

Problem: 

Bad code generated when plus equals, times equals or divide equals (+=, 

*-, /= ) with pointers to structure elements are used. Example: 

"C" 

"Z80" 

{■SEPARATE 0N$ 

struct fb { int i; int size; } x, y; 
ma int ) { 

struct fb *a,*b; 

a « &x; 

b - &y; 

b -> size =3; 

a -> size =4; 

if I b != a ) /* removing this line eliminates the problem */ 

a -> size += b -> size; /* wrong value stored in a-> size */ 

The result of a += is actually a->size = &a->size + b->size 

Temporary solution: 

Expand the expression as follows: 

a->size = a->size + b->size; 



Signed off 01/14/88 in release Z02.10 
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One-line description: 

ZDconvert library module has two errors in the ZDdwordtoword routine. 

Problem: 

The ZDconvert module contains two errors in the ZDsdwordtoword con- 
version utility. 
These errors cause two problems: 

First, if the data to be converted is located at an adress above or 
equal to 8000H the routine generates an overflow error trap, although 
there actually is no overflow. 

Second, if the data to be converted is negative, the stack gets 
misalligned, which will cause unpredictable results. 

The problem is restricted to the "debug" conversion routine, i.e. it 
will only occur if $DEBUG 0N$ is set in the source program. 

See the corrected Library Routine below for details: 
ZDsdwordtoword: 

CALL Zsave_address 

PUSH AF 

PUSH DE 

LD E,[HL] 

INC HL 

LD D,[HL] 
* check for overflow 

LD A,H ! ERROR 1 ! should be LD A,[HL] 

OR A 

JP M,NEG_DW0RD 

INC HL 



RET 
NEG_DW0RD INC HL 

LD A,[HL] 

INC HL 

AND [HL] 

EX DE.HL 

CP -1 

CALL NZ.Zoverflow 

RET ! ERROR 2 ! 

POP DE 
POP AF 

must be included before the return 
to be consistent with the POP's on 
entry of ZDsdwordtoword, because this 
is the second return point of this 
routine i 
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Temporary solution: 

No temporary solution, however you can turn SDEBUG 0FF$. 

Signed off 01/14/88 in release Z02.10 



Number: D200038778 Product: Z80/NSC800 C 



64824 



01.01 



One-line description: 

Incorrect transfer address when linking 9 or more files. 



Problem: 
I have files 
If you compi 
are assembly 
is the linke 
The address 
and in fact 
said he had 
I cannot dup 
problem with 
iled on the 
fully. 



submitted by a customer which have the following problem, 
le and assemble these files (most are C programs, a couple 

code) on the vax they will not link properly. What happens 
r reports transfer address at loc XXXX defined by Zlibrary 
it reports is different than the address of the ENTRY label 
is outside of the module Zlibrary altogether. The customer 
this problem when he linked eight or more files of any size, 
licate this with files I create, but, I can duplicate the 

the files he sent me. Incidently, if the files are comp- 
64000 and uploaded (relocs uploaded) they will link success- 



Temporary solution: 

Compile the files on the 64000 and upload the relocatables to the VAX. 

The 64000 generated reloc's will link successfully. 

Signed off 01/14/88 in release Z02.10 



Number: D200071373 Product: Z80/NSC800 C 



64824 



01.03 



One-line description: 

INT Multiplication of short by negative constant with SHORT_ARITH. 

Problem: 

When the compiler directive SSHORT^ARITH 0N$ is in effect 
multiplication of byte sized quantities by negative constants will 
produce code that extends the byte to int size and then preforms an 
int size multiplication operation. The following code illustrates: 

$SHORT_ARITH 0N$ 

short s; 

unsigned short us; 

main () 
{ 

if (s*-4) /* s is extended to int and a word mul performed */ 

error( ) ; 
if (us*0xfc) /* us is extended to int and a word mul performed */ 
error ( ) ; 
} 



Signed off 01/14/88 in release Z02.10 



SRB detail reports as of 01/14/88 
Number: D200071431 Product: Z80/NSC800 C 
Keywords: PASS 1 
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01.03 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 

Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SHORT_ARITH 0FF$ 

short s; 

unsigned short us; 



ma int ) 



} 



if ((s/usPOxffff) 

error ( ) : 
if ( (usXs) A 0x007f) 

error! ) 
if (us==s) 

error! ) ; 
if (s!=us) 

error! ) : 
if (s<us) 

error! ' 
if (s>us) 

error! ) ; 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z02.10 



Number: D200075044 Product: Z80/NSC800 C 
One-line description: 



64824 



Problem: 

Z80 COMPILER GENERATING INCORRECT CODE FOR THE FOLLOWING PROGRAM. 

"C" 
•■Z80" 

INT (*BGETVCO) 0; 

GETC(PARM) 
INT PARM; 

{ INT (*TEST)(); 

TEST = BGETVC(IO) ; 

RETURN! (TEST) (ll.PARM)); 
} 

- -8 



01.04 
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TEST CONTAINS AN ADDRESS WHICH POINTS TO A FUNCTION. WHEN IT IS 
ASSIGNED TO, THE CODE ASSIGNS THE CORRECT ADDR OF THE FUNCTION. 
HOWEVER, WHEN THE COMPILER GENERATES CODE TO CALL THE FUNCTION VIA 
TEST IT DOES NOT ACCESS TEST. INSTEAD IT ACCESSES A LOCATION TWO 
BYTES LOWER IN MEMORY. 

Signed off 01/14/88 in release Z02.10 



Number: D200077222 Product: Z80/NSC800 C 
Keywords: CODE GENERATOR 



64824 



01.04 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main( ) 

i 

\ 

double xx; 

xx = 2.0/3.0; 

xx = 2.0; 
i 
; 

xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx = 2.0/y; where y = 3.0; 

Signed off 01/14/88 in release Z02.10 



Number: D200079079 Product: Z80/NSC800 C 



64824 



01.04 



One-line description: 

+ ", --, *=, & /■ may fail to auto vars with $RECURSIVE ON$ 

Problem: 
Text: 

+ =, - = , * = , & /=■ may fail to auto vars with $RECURSIVE 0N$ 

SUBMITTER TEXT: 

Composite assignment operators may fail to automatic variables when 
$RECURSIVE 0N$ is in effect. This problem results from the compiler 
failing to keep track of how many bytes of parameters have been pushed 
onto the stack (and then popped off) for runtime library routines. 
The effect of this failure is an incorrect stack location being updated. 
The following program segment illustrates this problem. 
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"8085" 
SRECURSIVE 0N$ 

functil, i2,doub) 
int il , 12; 

double doub; 
{ 

int answer; 
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answer 



1; 



answer += i2*x; /* after this statement answer still is 1 */ 



7 



/* however i 1 = 12 



Signed off 01/14/88 in release Z02.10 

Number: D200080374 Product: Z80/NSC800 C 64824 01.04 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 

"C" 

"68000" 

unsigned int a; 

main!) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 

Signed off 01/14/88 in release Z02.10 



Number: D200081471 Product: Z80/NSC800 C 

One-line description: 

MOD operation returning the wrong value. 

Problem: 

The MOD operator is returning the wrong value. 



64824 



01.04 
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"BZ80" 






Number: 5000226605 Product: Z80/NSC800 C 300 64824S004 01.20 


PROGRAM TEST; 






One-line description: 


{.EXTENSIONS 0N$ 






Double word divide library returning incorrect result. 


$GL0BVAR 0N$ 






Problem: 


VAR 11,12,13: INTEGER; 






Zsdworddiv calculates incorrectly. The result calculated becomes 1, 
if it was incorrect. 


BEGIN 






Zsdworddiv is correct on 64000. This is the problem on 9000/300. 
The example is as followes, 


11 := 5280; 








12 := 1000; 






"C" 


13 : = 11 MOD 12; 






"Z80" 

long a.b.ldiv; 


END. 






main( ) 
{ 

a=70000; 








The result of the mod operation is 


4280 decimal. 




b=150; 

ldiv = a/b; < ldiv must be 01D2H but it is 1 ! 


Temporary solution: 






} 


No temporary solution at this time 






Temporary solution: 


Signed off 01/14/88 in release 402 


10 




No temporary solution at this time. 








Signed off 01/14/88 in release Z02.10 
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Number: 1650011585 Product: Z80/NSC800PASCAL 

Keywords: PASS 2 



64823 
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01.01 



One-line description: 

Incorrect code generated when set elements are passed as parameters. 

Problem: 

Incorrect code is generated when sets are passed as parameters. 
The stack pointer is manipulated so that the program "goes in the 
weeds" after the call to the procedure. The following code is 
an example: 

"processor name" 
^SEPARATE ONI 
^.EXTENSIONS 0N$ 
TYPE 

Letters = (a,b,c,d,e, f ,g,h, i, j ,k, l,m,n,o,r) ; 

Set_of_Letters = SET OF Letters; 
$GL0BPR0C 0N$ 

PROCEDURE Letters_Pas(Received:Set_of_Letters):EXTERNAL; 
PROCEDURE Init_Set; 
BEGIN 

Letters_Pas( [] ) ; (*Code generates an extra INC SP after the 
END; call to Letters_Pas*) 

$GL0BPR0C 0FF$ 

Temporary solution: 

Any set size which is not equal to 3 bytes will work correctly. 

Signed off 01/14/88 in release Z01.90 



Number: 5000161000 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

Unbelieveable amount of library code linked for no-line program. 

Problem: 

The following no-line program yields a 4000 byte absolute file 

when linked with Zlibrary and Zreallib. 

"BZ80" 

PROGRAM L0TS_0F_C0DE; 

PROCEDURE REAL ADD; EXTERNAL; 

BEGIN 

END. 

Several modules that seem to be unnecessary (e.g. REAL_ADD,REAL_ATAN, 
REALJIUL) are loaded. Since the address space of the Z80 is only 
64K, the libraries should be written in such a way to minimize the 
code loaded. 

Signed off 01/14/88 in release Z01.90 



- -8 
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Number: 5000161034 Product: Z80/NSC800PASCAL 



64823 
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01.03 



One-line description: 

Libraries reference procedures not actually needed. 

Problem: 

The following code requires the lib, reallib, piolib, and simlib 

to be linked so that no linker errors are generated. 

"BZ80" 

PROGRAM SIM; 
VAR 

REAL_S : STRING; 

X : REAL; 

P,Q : INTEGER; 
BEGIN 

P :- 1; 

STRWRITE ( REAL_S , P , Q , X ) ; 

STRREAD(REAL_S,P,Q,X); 
END. 

Linking all of the libraries causes the absolute file to be 
17000 bytes long. 

Signed off 01/14/88 in release Z01.90 



Number: 5000163287 Product: Z80/NSC800PASCAL 



64823 



One-line description: 

Code generated by compiler increased 12% with latest version. 

Problem: 

Latest revision of the compiler generates approximately 12% more 
code then the previous revision did, according to this customer. 
The following example was submitted showing a piece of code that 
generated 2 lines of code with the previous version, and now 
generates 7 lines of code with the most recent version. 



"BZ80' 






PROGRAM DUMMY; 




CONST 






C S 


- 32; 




TYPE 






PI - 


RECORD 






C : SIGNED 


16 




END; 




VAR 






LED 


: Pi; 




PROCEDURE A; 




BEGIN 






LED. 


C :- C S; 


*G 


END; 






BEGIN 






LED 


C :- C S; 




END. 







01.04 



Generates 7 lines of code, used to generate 2*) 



SRB detail reports as of 01/14/88 



Signed off 01/14/88 in release Z01.90 
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Number: 5000182014 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

FOR statement with SIGNED_BYTE produces incorrect code. 

Problem: 

Bad code generated when FOR statement requires a signed byte 

mod library call. Example: 

" BZ80 " 

$EXTENSI0NS 0N$ 

VAR 

A,B:BYTE; 
BEGIN 

FOR A:=(B MOD 64) TO 100 DO 

END. 

The problem is that a temporary storage location is set up for the 
FOR loop counter, but after the initial value of the mod is 
calculated, register A is loaded from this location temporary storage 
location instead of being stored there. 



SRB detail reports as of 01/14/88 
or use type INTEGER instead of BYTE. 
Signed off 01/14/88 in release Z01.90 
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Number: 5000190629 Product: Z80/NSC800PASCAL 



64823 



01.04 



One-line description: 

Bad code generated when CASE expression involves addition of two bytes. 

Problem: 

Bad code generated when CASE statement expression is the addition 

of two BYTEs: 

"BZ80" 

$EXTENSIONS+$ 

PROGRAM BUG_PR0G; 

PROCEDURE BUG; 

VAR 

A,B,C:BYTE; 
BEGIN 

A:-l; B:=2; 

CASE A+B OF 

: C:=0; 

1 : C:-l; 

2 : C:=2; 



Temporary solution: 


3 : C:=3; OTHERWISE C:=100; END END; 


Use UNSIGNED_8 instead of BYTE, or declare a temporary variable 




to hold the result of the mod operation. 






Temporary solution: 


Signed off 01/14/88 in release Z01.90 


1. Store the result of A+B in a temporary value, then CASE on that 




temporary value. 


Number: 5000186742 Product: Z80/NSC800PASCAL 64823 01.03 


2. Use INTEGER (A+B) 




3. Declare A and B as type INTEGER 


Keywords: ADDR 






Signed off 01/14/88 in release Z01.90 


One-line description: 




ADDR(x) generates incorrect code is x is of type BYTE. 


Number: 5000217927 Product: Z80/NSC800PASCAL 64823 01.04 


Problem: 


One-line description: 


Incorrect code generated when using ADDR function if taking the 


Signed_32 divide returns wrong result. 


address of a local variable of type "BYTE". EXAMPLE: 




"BZ80" 


Problem: 


PROGRAM TEST; 


The library Zsdworddiv improperly handles some signed 32 bit 


$EXTENSIONS 0N$ 


divisions. Example: 


SRECURSIVE 0N$ 


"BZ80" 




PROGRAM DIVIDE; 


PROCEDURE RUN; 


VAR 


VAR 


B1,B2,B3:SIGNED 32 


ONE: BYTE; 


BEGIN 


ONE POINTER:~BYTE; 


Bl:=362700; 


BEGIN 


B2:=2000; 


ONE POINTER: =ADDR(0NE); 


B3:=B1/B2; {the result returned is one} 


END; 


END 


An incorrect value is written to 0NE_P0INTER 






Temporary solution: 


Temporary solution: 


No temporary solution at this time. 


Use $RECURSIVE 0FF$, or declare 0NE_P0INTER outside the procedure, 




- -8 


- -8 
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Signed off 01/14/88 in release Z01.90 
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Number: D200063875 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 



"processor" 




PROGRAM BAD_DATA; 


TYPE EVENT ■ 
A 
B 
C 
D 
END; 


■ RECORD 
BYTE; 
BYTE; 
INTEGER; 
BYTE; 


V'AR EVENT 1 


: EVENT; 


PROCEDURE 
BEGIN 

EVENT 1 
END ; 


GENERATOR ( ) 
:= EVENT (0 



{ THIS ASSIGNMENT RESULTS IN BAD DATA } 
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END; 
VAR 

LED : PI; 

PROCEDURE A; 
BEGIN 

LED.C := C_S; (*Generates 7 lines of code, used to generate 2*) 
END; 

BEGIN 

LED.C := C_S; 
END. 

Signed off 01/14/88 in release Z01.90 



Number: D200071332 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

Links not correctly established during calls of nested procedures. 

Problem: 

Calls between procedures at different nesting levels may not correctly 
establish links needed for referencing higher level variables. The 
following code illustrates the problem. 



"PASCAL" 
"BZ80 " 

SEXTENSIONS 0N$ 
$RECURSIVE 0N$ 



END. 


PROGRAM BUG1018B; 


Temporary solution: 


PROCEDURE TEST1018B; 


No temporary solution at this time. 


VAR 




LOCAL 10 18 : INTEGER ; 


Signed off 01/14/88 in release Z01.90 






PROCEDURE INC LOCAL ; 


Number: D200066761 Product: Z80/NSC800PASCAL 64823 01.03 


BEGIN 




L0CAL1018 := L0CAL1018 + 1; 


One-line description: 


END ; 


Code generated by compiler increased 12% with latest version. 






PROCEDURE NEST1 ; 


Problem: 


VAR 


Latest revision of the compiler generates approximately 12% more 


DUMMY 1 : INTEGER ; 


code then the previous revision did, according to this customer. 




The following example was submitted showing a piece of code that 


PROCEDURE NEST2 ; 


generated 2 lines of code with the previous version, and now 


VAR 


generates 7 lines of code with the most recent version. 


DUMMY 2 : INTEGER ; 




BEGIN { NEST2 } 


"BZ80" 


INC LOCAL ; (* variable local is NOT correctly incremented *) 


PROGRAM DUMMY; 


END ; { NEST2 } 


CONST 




C S = 32; 


BEGIN { NEST1 } 


TYPE 


INC LOCAL ; (* variable local is correctly incremented *) 


PI = RECORD 


NEST 2 ; 


C : SIGNED_16; 


END ; { NEST1 } 


- -8 


- -8 
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BEGIN { TEST1018B } 
LOCAL1018 := ; 
NEST1 ; 

END ; { TEST1018B } 



Signed off 01/14/88 in release Z01.90 
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Number: D200071340 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

Certain variable accesses by nested procedures may not work 

Problem: 

In certain situations where a local variable of one procedure is 
referenced by another procedure nested inside the first procedure, 
the register loaded with the link may be walked on. The following 
code illustrates the problem. 



"PASCAL" 
"BZ80" 

SEXTENSIOMS 0N$ 
SRECURSIVE ON$ 

PROGRAM BUG1018A; 



PROCEDURE LEVEL1 ; 
VAR 

LEV1_1, LEV1_2 



INTEGER 



PROCEDURE LEVEL2 ; 
VAR 

ARR1 : STRING ; 

INDEX : INTEGER ; 

BEGIN { LEVEL2 } 

ARR1 [INDEX] :- CHR UEV1_2 + 1) 
END ; { LEVEL2 > 

BEGIN { LEVEL1 } 

LEVEL2 ; 
END ; { LEVEL 1 } 



Signed off 01/14/88 in release Z01.90 



{ access to LEV1_2 incorrect } 



Number: D200071365 Product: Z80/NSC800PASCAL 
Keywords: PASS 1 



64823 



01.03 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 



"-* "* ' - -' -" - 



SRB detail reports as of 01/14/88 

the following code illustrates the problem. 

SEXTENSIONS 0N$ 
PROGRAM PTEST; 
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VAR 

S8 
U8 
S16 
U16 

BEGIN 
U16 
U16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



UNSIGNED_16(S8) 
UNSIGNED 8(S8) ; 



(* signed extension of S8 
(* signed extension of S8 



correct *) 
incorrect 



S16 :- SIGNED_16(U8); 
S16 :- SIGNED 81U8) ; 



END. 



(* unsigned extension of U8 - correct *) 
(* unsigned extention of U8 - incorrect 



Signed off 01/14/88 in release Z01.90 

Number: D200071423 Product: Z80/NSC800PASCAL 64823 01.03 

One-line description: 

Function Calls via pointer may fail 

Problem: 

Function calls via pointers may fail. The following code sample 

illustrates the problem: 

typedef int (*PFI)(); 

extern int code_array[100] ; /* code_array is actually a function */ 

main! ) 
{ 

(*( (PFI)code_array) ) () ; /* this call fails to transfer 

control to code array */ 
LXI H,main01_0 
PUSH H 
LHLD code_array /* the instruction should be 

LXI H,code_array */ 
PUSH H 
RET 

mainOl 



} 

Temporary solution: 

typedef int (*PFI) ( ) ; 

PFI func_ptr; 

extern int code_array[l00] ; /* code_array is actually a function */ 

main( ) 



SRB detail reports as of 01/14/88 
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{ 



func_ptr = code_array; 

(*func_ptr) () ; /* call to code_array is correct */ 



Signed off 01/14/88 in release 201.90 



Number: D200073031 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 

changes physical size), when it should generate a fatal error. It 

tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPROCESS 
"6809" 

{ Test program to demonstrate Pascal language defect } 
{ Functional type change of constant to multi-byte variable } 
PROGRAM PTEST101; 
^EXTENSIONS 0N$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR event 1: event; 
i: INTEGER; 
R: REAL; 

BEGIN 

{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 
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eventl := event(O); {This code is incorrect Pascal} 



{Correct Pascal using individual assignments} 

eventl. type: =0 ; 

event l.qualif ier:=0; 

eventl.msg:=0; 

eventl . send_task : =0 ; 
END. 



Signed off 01/14/88 in release Z01.90 



Number: D200076067 Product: Z80/NSC800PASCAL 



64823 



01.04 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

SEXTENSIONS 0N$ 

PROGRAM D0L00P; 



VAR SECTORNUM, STOPSECTOR 
A 



: UNSIGNED_8; 
: INTEGER; 



BEGIN 

STOPSECTOR := UNSIGNED_8(247) ; 

FOR SECTORNUM := UNSIGNED_8(0 ) TO STOPSECTOR DO BEGIN 

A := 5; 

END; 

END. 

Temporary solution: 

USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 

"PROCESSOR" 
SEXTENSIONS ON$ 
PROGRAM D0L00P; 

VAR SECTORNUM, STOPSECTOR : UNSIGNED_16; 

- -8 
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A : INTEGER; 
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BEGIN 



STOPSECTOR : = UNSIGNED_16(247) ; 

FOR SECTORNUM : = UNSIGNED_16 (0 ) TO STOPSECTOR DO BEGIN 

A := 5; 
END; 
END. 

This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.90 



Number: D200079301 Product: Z80/NSC800PASCAL 



64823 



01.04 



One-line description: 

Compiler may confuse similar parameters in different subroutines 

Problem: 

The Z80 & 8085 B Pascal compilers may confuse similar parameters in 
different (but nested) subroutines. The following program illustrates 
this problem. The problem stems from the compiler searching for a 
parameter in a register. It finds one with the correct attributes 
(position, size, indirects, data type, etc), but it is unfortunately 
not from the correct subroutine. 

•'PASCAL" PREPR0CESS 
"BZ80" 

{EXTENSIONS 0N$ 
{SEPARATE 0N$ 
{RECURSIVE 0N$ 

PROGRAM PTEST104; 

PROCEDURE TEST1018; { Test problems in Pascal Scoped_ACCESSES; } 

PROCEDURE Levell(llpl,llp2:BYTE) ; 
VAR 

llvl,llv2: BYTE; 

PROCEDURE Level2(12pl, 12p2:BYTE) ; 
VAR 

12vl,12v2: BYTE; 

BEGIN {Level2} 

12p2:=llv2; 

llvl:=llp2; { ERROR llvl gets the value of 12p2 rather than llpl. } 
END; { The value of 12p2 was in a register from the } 
{ previous assignment. 

BEGIN {Levell} 



SRB detail reports as of 01/14/88 

END; 

BEGIN {TEST1018} 
END; 



Temporary solution: 
No temporary solution. 

Signed off 01/14/88 in release 301.90 
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Number: 5000224204 Product: Z80/NSC800PASCAL VAX 64823S003 01.70 

One-line description: 

Nested external procedure call causes bad code to be generated. 

Problem: 

Bad code is generated when a procedure which is declared external 

within a second procedure that passes parameter (s) to a third. 

Example: 

"BZ80" PREPR0CESS 
PROGRAM HAROLD; 
$EXTENSI0NS+$ 
VAR B:BYTE; 
PROCEDURE ERROR ; 

PROCEDURE CLR_PRTB( MASK 
BEGIN 

CLR_P0RTB( B ) ; 
END; 



BYTE ) ; EXTERNAL 



Temporary solution: 

WORKAROUND: declare PROCEDURE CLR_P0RTB (MASK: BYTE ); EXTERNAL; 

in the outer scope of the module, not inside the procedure. 

Signed off 01/14/88 in release Z01.90 



SRB detail reports as of 01/14/88 
Number: D200076760 Product: Z8000 C 



Page: 146 

64820 01.06 



One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 

"C" 

"Z80" 

char array[12]; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASM_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 01/14/88 in release Z02.10 



Number: D200077107 Product: Z8000 C 
Keywords: CODE GENERATOR 



64820 



01.06 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main( ) 
{ 



} 



double xx ; 
xx = 2.0/3.0; 
xx = 2.0; 



xx is assigned the value 2.0 by both statements. 



This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx = 2.0/y; where y = 3.0; 

Signed off 01/14/88 in release Z02.10 



Number: D200079137 Product: Z8000 C 
Keywords: PASS 1 



64820 



01.03 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 
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Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 

$SHORT_ARITH 0FF$ 

short s; 

unsigned short us; 



ma in I 

{ 



if Us/usPOxffff) 

error! ) : 
if Uus'/.s) 0x007f) 

error! ) : 
if (us==s) 

error! ) 
if (s!=us) 

error! ) 
if (s<us) 

error! ) 
if (s>us) 

error! ) 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z02.10 



Number: D200080341 Product: Z8000 C 64820 01.06 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 

"C" 

"68000" 

unsigned int a; 

main! ) 

{ 

a=0.0; 

} 

NOTE: this, error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 

- -8 
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Signed off 01/14/88 in release Z02.10 
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Number: D200063834 Product: Z8000 PASCAL 



64816 
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01.11 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 

"processor" 

PROGRAM BAD_DATA; 

TYPE EVENT = RECORD 



A 


BYTE; 


B 


BYTE; 


C 


INTEGER; 


D 


BYTE; 


END; 





VAR EVENT 1 : EVENT; 



PROCEDURE GENERATOR ( ) ; 
BEGIN 

EVENT1 := EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA } 
END; 

BEGIN 
END. 



Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z01.90 



Number: D200076026 Product: Z8000 PASCAL 



64816 



01.12 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

SEXTENSIONS 0N$ 

PROGRAM D0LO0P; 



VAR SECTORNUM.STOPSECTOR 
A 



UNSIGNED 
INTEGER; 
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BEGIN 

ST0PSECT0R := UNSIGNED_8(247); 

FOR SECTORNUM := UNSIGNED_8(0) TO STOPSECTOR DO BEGIN 
A := 5; 

END; 
END. 
Temporary solution: 

USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 

"PROCESSOR" 
SEXTENSIONS 0N$ 
PROGRAM D0L0OP; 
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VAR 



BEGIN 



SECTORNUM , STOPSECTOR 
A 



UNSIGNED_16; 
INTEGER; 



END. 



STOPSECTOR := UNSIGNED_16(247) ; 

FOR SECTORNUM := UNSIGNED_16(0) TO STOPSECTOR DO BEGIN 

A := 5; 
END; 



This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.90 



Number: D200079210 Product: Z8000 PASCAL 



64816 



01.12 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The P.ascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

, The Pascal/64000 compiler does report an error 505 (Warning: type 
changes physical size), when it should generate a fatal error. It 
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tries to generate code for the illegal statement which will not 










produce the results expected by the user. 


SEXTENSIONS 0N$ 






The compiler should produce fatal Error #451: Structured constants not 


PROGRAM 


PTEST; 






implemented. 


VAR 








Here is a simple example and the workaround by explicit individual 


S8 


: SIGNED 8 ; 






assignment statements. 


U8 

S16 

U16 


: UNSIGNED 8 ; 
: SIGNED 16 ; 
: UNSIGNED_16 ; 






"PASCAL" PREPROCESS 










"6809" 


BEGIN 








{ Test program to demonstrate Pascal language defect } 


U16 


:= UNSIGNED 16 (S8) 


; (* signed extension of S8 - 


correct *) 


{ Functional type change of constant to multi-byte variable } 


U16 


:= UNSIGNED_8(S8); 


(* signed extension of S8 - 


incorrect *) 


PROGRAM PTEST101; 










SEXTENSIONS 0N$ 


S16 


:= SIGNED 16(U8); 


(* unsigned extension of U8 


- correct *) 


TYPE event = RECORD 


S16 


:= SIGNED_8(U8); 


(* unsigned extention of U8 


- incorrect *) 


type : BYTE; 


END. 








qualifier: BYTE; 










msg : INTEGER; 


Signed off 01/14/88 in rel 


sase Z01.90 




send task: BYTE; 










END; 










VAR event 1: event; 










i: INTEGER; 










R: REAL; 










BEGIN 

f TVio f nl Inuina r-r\r\o > a att ftmnt tt-io +r> in i t ial i 70 \ 











{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 

eventl := event(O); {This code is incorrect Pascal} 



{Correct Pascal using individual assignments} 

eventl. type: =0 ; 

eventl .qualifier: -0 ; 

eventl. msg: =0; 

event 1 . send_task : =0 ; 
END. 



Signed off 01/14/88 in release Z01.90 
Number: D200079277 Product: Z8000 PASCAL 
Keywords: PASS 1 



64816 



01.12 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



SRB detail reports as of 01/14/88 

Number: 5000137869 Product: Z8002 EMULATION 64233 

One-line description: 

Monitor displays wrong value for R15 and SSTK 

Problem: 

When displaying register contents, the value shown for 
R15 and SSTK is 6 (six) less than it should be. This 
is a result of the way the monitor is entered. 



Temporary solution: 

Modify the emulation monitor as follows: 

440 LD M0NR14L.R14 
NEW INC R15,#6 

441 LD M0NR15L.R15 
NEW INC M0NSSTKL,#6 



709 ************************* 
NEW DEC M0NSSTKL,#6 

Signed off 01/14/88 in release 202.01 

Number: 5000151431 Product: Z8002 EMULATION 
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SRB detail reports as of 01/14/88 

Number: D200071415 Product: Z8002 EMULATION 



64233 
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02.00 



One-line description: 

Can't find symbols loaded with more address bits than specified. 

Problem: 

If the user links his code with more significant address bits 
than the number specified in the emulation configuration, the 
emulator will be unable to access the symbols, and the monitor 
may not function properly. 

Signed off 01/14/88 in release Z02.01 
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02.00 



One-line description: 

User interrupts are not serviced for 17ms after analysis generated break 



Problem: 

Starting with revision 1.07 of the emulation opera 
STOP line is asserted over a 17ms period with a du 
asserted, followed by 40us of time with the STOP 1 
Version 1.06 of the emulation software similarly a 
but for only approximately 2.3ms with a 50% duty c 
followed by 40us off. The problem comes with the 
will suspend all operations while the STOP line is 
version 1.07 of the software, there is a period of 
the cpu will only be active for 1.2ms If user in 
more often than every 17ms and the interrupt servi 
more than 1.2ms to complete, then user interrupts 
NOTE: This problem occurs only after an analysis 
Therefore you may only see the problem afte 
trigger/measurment_complete" , or "run until 



ting software, the 

ty cylce of 520us 

ine disasserted. 

sserted the STOP line 

yle of 40us on, 

fact that the cpu 
asserted. So with 
17ms during which 

terrupts occur 

ce routine takes 

will be missed. 

generated break. 

r "trace break_on 
<state>" . 



Version i.07 is essentially equivalent to version 2.00 with 
regard to this problem. 

Temporary solution: 

Contact your HP representative if you encounter this problem. 
Ke should be able to get you a copy of the software that 
solves this problem until the new revision of software is 

available. 

Signed off 01/14/88 in release Z02.01 
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